D10494: update handle- icons for kirigami

colomar added a comment. Now it has the same icon as the handle for the Context Drawer. On the one hand that's good because they do very similar things, but on the other hand if an app uses both, it could be a bit confusing REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricato

D8536: Add more hashing algorithms to KPropertiesDialog

colomar added a comment. In https://phabricator.kde.org/D8536#181775, @petermajchrak wrote: > I can revert it back to the combobox based layout. Don't we have some UX people that could take a look at this? Yes, me :) Which is what I did, and commented with my recommendation. REPO

D8536: Add more hashing algorithms to KPropertiesDialog

colomar added a comment. With that many available algorithms, the combobox solution makes more sense to me as well. For checking a provided checksum, users don't have to use the combobox, anyway. They just paste in the checksum and get a result automatically. REPOSITORY R241 KIO REVI

D8773: Improve discoverability of drag-and-drop of toolbar actions

colomar added a comment. In https://phabricator.kde.org/D8773#167607, @broulik wrote: > What I would like to see is that when you open the "Edit Toolbar" dialog that you then can drag around tool bar buttons and drag them from and to the dialog, like Firefox does it and how @colomar sugg

D8773: Improve discoverability of drag-and-drop of toolbar actions

colomar added a comment. Why don't we do this the way Firefox does it: Have a menu entry that puts the whole UI in config mode. That works far better then trying to make each individual config feature discoverable. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D8

[Differential] [Commented On] D4663: Allow setting the timeout value.

colomar added a comment. > even Windows and Mac have deprecated them in favor of persistent notifications! > Not only it's already implemented, but also it is what every major desktop and phone OS out there already use! SNIS != those legacy systray icons which were rightfully abolishe

[Differential] [Commented On] D4663: Allow setting the timeout value.

colomar added a comment. I agree that what Android does makes a lot of sense. What they have is - a permanent icon in the top bar for each application that still has an open notification - basically an SNI, minus the direct interactivity (which makes sense given that tiny icons are not m

[Differential] [Commented On] D4142: Support "default actions", as specified in [1].

colomar added a comment. >>>! In https://phabricator.kde.org/D4142#77861, @colomar wrote: >> Hm, that's not easy to decide. Whether one likes the "click to make go away" behavior or not is highly subjective. I, for one, find it very annoying on e.g. OS when a notification covers somethi

[Differential] [Commented On] D4142: Support "default actions", as specified in [1].

colomar added a comment. Hm, that's not easy to decide. Whether one likes the "click to make go away" behavior or not is highly subjective. I, for one, find it very annoying on e.g. OS when a notification covers something I want to see on the screen and there is no way to make it go away ot

Re: Review Request 129607: Display Application version in About dialog header

> On Dec. 3, 2016, 4:48 p.m., Martin Klapetek wrote: > > How about "Using" for the title of the tab and then removing the "Using" > > label from inside the tab? > > > > Also, +1 to putting the version front. Hm, "Using" sounds a bit weird without context, but "Libraries" or maybe "Libraries u

Re: Review Request 128661: [KTreeWidgetsSearchLineWidget] Use placeholderText instead of separate label

> On Aug. 14, 2016, 7:17 p.m., Thomas Pfeiffer wrote: > > Actually, this is in violation of the current search HIG ( > > https://community.kde.org/KDE_Visual_Design_Group/HIG/SearchPattern ), but > > since the de-facto standard in our software and elsewhere is an inline &

Re: Review Request 128661: [KTreeWidgetsSearchLineWidget] Use placeholderText instead of separate label

( https://community.kde.org/KDE_Visual_Design_Group/HIG/SearchPattern ), but since the de-facto standard in our software and elsewhere is an inline hint, I suppose we should update the HIG. So yes, +1, good change! - Thomas Pfeiffer On Aug. 12, 2016, 8:22 a.m., Kai Uwe Broulik wrote

Re: Review Request 128490: Checksums tab: replace groupbox with vertical separator

good compromise. - Thomas Pfeiffer On July 20, 2016, 1:01 p.m., Elvis Angelaccio wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

g the groupbox altogether, as it's not providing any > semantic value. > > Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF > > Sebastian Kügler wrote: > This looks logical to me, and it's simpler: Very good! > > (Take tha

Re: Review Request 128466: Rename Checksums tab to Integrity

> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote: > > Please don't ship it, yet. > > > > > > I find the UI illogical. There's a groupbox grouping the checksum buttons, > > but then you can input the checksum above, so essentially, the groupbox is > > unnecessary and confusing. > > > >

Re: Review Request 128283: Add checksums tab to the properties dialog

> On July 9, 2016, 1:05 p.m., Ragnar Thomsen wrote: > > Another post-commit suggestion: > > - The "Share" label is not obvious to me. This was also pointed out by > > another user on the [blog post](http://www.aelog.org/checksums-made-easy). > > Something like "Calculated checksums" would mak

Re: Review Request 128413: Add clipboard buttons in the Checksums tab

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128413/#review97264 --- +1, makes it even easier! - Thomas Pfeiffer On July 9

Re: Review Request 128283: Add checksums tab to the properties dialog

> On June 26, 2016, 12:13 p.m., Luigi Toscano wrote: > > When the verify operation is executed, shouldn't the computed checksum be > > (immediately) shown in the corresponding text box? Makes sense, since it's then already calculated anyway. - Thomas

Re: Review Request 128283: Add checksums tab to the properties dialog

> On June 27, 2016, 12:16 p.m., Thomas Pfeiffer wrote: > > Thank you for implementing the suggestion! > > There are still some issues with it: > > 1. HIG says "Avoid using color as a primary method of communication". A > > red-green blind person would ha

Re: Review Request 128283: Add checksums tab to the properties dialog

hich shows further instructions if the checksums don't match, e.g. "This may be due to a faulty download. Try re-downloading the file. If the verification still fails, contact the source of the file." 4. What happens if you type the checksum in manually? At witch point does

Re: Review Request 128283: Add checksums tab to the properties dialog

ey'd need a way to generate it manually. Even then, however, how likely is it they'd need all three? For this story I'd provide either three different "Calculate Checksum" buttons or one drop down button to select which one to calculate, and then calculate only that

[Differential] [Updated] D1942: [KIconDialog] Do not clear search line when switching category

colomar added a comment. Yes, this makes sense! Clearing a search field automatically is only useful if the query simply does not make sense in the new context anymore, which is not the case here. For the future: If you want usability or general design input, you can add the VDG group t

Re: Review Request 128019: Remove F1 as standard shortcut for Help

> On May 26, 2016, 3:37 p.m., Matthew Dawson wrote: > > While I appreciate the source of this change (I've almost never hit F1 > > intending to open the doucmentation myself), I don't think a RR is the > > right place to discuss changes to our default shortcuts. This takes a > > small survey

Re: Review Request 128019: Remove F1 as standard shortcut for Help

> On May 26, 2016, 12:12 a.m., Thomas Pfeiffer wrote: > > As Kai said: Activating the help cursor by pressing F1 (and actually > > putting useful help behind it!) would be a great thing to have from a > > user's perspective. > > Contextual help would be much mo

Re: Review Request 128019: Remove F1 as standard shortcut for Help

The question is: Do we think there is a chance to get developers to actually put useful contextual help in their UIs in the the future, or will it likely just be doing nothing in the vast majority of apps? - Thomas Pfeiffer On May 25, 2016, 11:01 p.m., Albert Astals Cid

Re: Review Request 127127: KOpenWithDialog: show mimetype name and comment in "Remember" checkbox text

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127127/#review92657 --- +1 from the usability side, great improvement! - Thomas

Re: Review Request 127046: Move popup menu image actions into a submenu

used. I don't see why viewing, copying or saving an image is less frequently done than the same things regarding the link. Can't we have those three still on the first level and then a "More..." option with further actions? - Thomas Pfeiffer On Feb. 11, 2016, 6:18 p.

Re: Review Request 126949: Remove Air and Oxygen themes

sma theme that > is utterly broken and unmaintained. > > andreas kainz wrote: > I'v never done a plasma theme but I saw how the breeze theme get broken > and how it was fixed again. As Hugo maintaine oxygen stuff and I maintain > oxygen icon stuff, it would be good to

Re: Review Request 126949: Remove Air and Oxygen themes

> On Feb. 1, 2016, 8:12 p.m., andreas kainz wrote: > > Hi, I know I say I will keep oxygen-icons5 up to date, and I hope I get the > > time I need the plasma oxygen theme too to give the user the one single > > click feature (look & feel package). Is there an space where you can move > > "unma

Re: Review Request 126523: Use a KMessageWidget in KNewPasswordDialog

> appearing is really under your direct control anyway. > > Thomas Pfeiffer wrote: > I agree with Kai: No need for a close button there, since the message > widget disappears anyway as soon as the user fixes the problem. > > Heiko Tietze wrote: > Not so

Re: Review Request 126523: Use a KMessageWidget in KNewPasswordDialog

> On Dec. 27, 2015, 9:21 a.m., Heiko Tietze wrote: > > Perfect use of the message panel. However, the red close icon does not work > > (well) with colored backgrounds. > > Kai Uwe Broulik wrote: > Do we even need the close button to begin with? It's not like it > appearing is really under

Re: Review Request 126505: Do not show a warning color before the user even started typing

from typing e.g. 10 more characters before being informed about the mistake they made in the second character Otherwiese it sounds good! - Thomas Pfeiffer On Dec. 24, 2015, 5:53 p.m., Elvis Angelaccio wrote: > > --- > This is an au

Re: Review Request 126426: Add a warning color to kwalletd's password dialogs

only be marked when it loses focus, otherwise it always has the error state while the user is typing. If that's already the case, then I'm all +1 - Thomas Pfeiffer On Dec. 21, 2015, 7:20 p.m., Elvis Angelaccio wrote: > >

Re: Review Request 125619: Refactor KNewPasswordDialog class

> On Oct. 13, 2015, 1:33 p.m., Aleix Pol Gonzalez wrote: > > File Attachment: knewpassworddialog4.png - knewpassworddialog4.png > > > > > > Shouldn't it have a red background when empty as well? > > Elvis Angelaccio wrote: > I'm not

Re: Review Request 123929: If double-click is on empty area, then invoke back. (kfilewidgets)

> On May 29, 2015, 12:45 p.m., David Faure wrote: > > I'm not sure this is a good idea, usability wise. Miss an icon by one > > pixel, and the effect is to go up, making the whole set of icons disappear? > > Ashish Bansal wrote: > Well about usability there's already discussion going on dol

Re: Review Request 118289: Change titlewidget from bold to increased font size

> On May 27, 2014, 9:56 a.m., Christoph Feck wrote: > > I'll leave the decision which factor to use to the VDG. To get feedback from the VDG, I'd suggest adding alake to the request, he's our expert on those matters. - Thomas --- This