D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  One last word about the necessity of this arrow. To me the arrow is mandatory 
as soon as it refers to an action that is different than the one of the icon. 
(either long press, or extra menu beside the icon main action). Still to me, 
opening a menu when pressing the icon is a single action, so you should not 
need two controls. This is as much a single action as when pressing an icon 
opens a dialog, (like in save as), or a confirmation dialog (like "do you 
really want to discard changes to the document), and for which we have no 
visual indication either that it will be different from say, sending the email.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: zzag, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  In D13064#267463 , @ngraham wrote:
  
  > Got the chance to test this out.  Functionally, it works great, and 
resolves the issue!
  >
  > Visually, I can understand you guys's hesitation about bringing the arrows 
back, because they do seem to lack that //je-ne-sais-quoi//, somehow. I wonder 
if the arrow might look nicer if it was vertically centered, instead of 
appearing towards the bottom of the button. The downward-pointing arrow is 
centered in other Breeze contexts (comboboxes and drop-down menu buttons, for 
example).
  >
  > Perhaps we could experiment with different arrow appearances so that they 
feel more natural? I feel like these arrows can work great in other non-Breeze 
contexts. Thunderbird, for example:
  >
  > F5865940: Screenshot_20180523_212216.png 

  
  
  Vertically centered arrows we also already use, and they correspond to 
buttons for which the button itself and the arrow are two different actions. 
  See: F5866110: Screenshot_20180524_075343.png 

  (from oxygen-demo 5)
  
  The use of an off centered, slightly smaller arrow located closer to the icon 
is to convey the information that it is not a different action, but "the same". 
  Other themes (most Qt themes in fact) use the same convention.
  I do not think changing the arrow style will improve the situation much, and 
on the contrary might introduce inconsistency in the style with respect to 
other arrows. If this path is to be followed, it must be part of a more 
conscious revisiting of the breeze widget style, and not an isolated change.
  
  Finally, one should also check how this looks when enabling text beside, or 
below the icons (two options that we support). Trying so you will see that this 
is looking even worse. This is true for breeze, but also for all the other Qt 
styles around that I could check.
  
  This is what I meant in the bug report when saying that the main reason why I 
disabled the arrow was a lack of good design for it.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: zzag, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Nathaniel Graham]

ngraham added a comment.


  Got the chance to test this out.  Functionally, it works great, and resolves 
the issue!
  
  Visually, I can understand you guys's hesitation about bringing the arrows 
back, because they do seem to lack that //je-ne-sais-quoi//, somehow. I wonder 
if the arrow might look nicer if it was vertically centered, instead of 
appearing towards the bottom of the button. The downward-pointing arrow is 
centered in other Breeze contexts (comboboxes and drop-down menu buttons, for 
example).
  
  Perhaps we could experiment with different arrow appearances so that they 
feel more natural? I feel like these arrows can work great in other non-Breeze 
contexts. Thunderbird, for example:
  
  F5865940: Screenshot_20180523_212216.png 


REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: zzag, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Nathaniel Graham]

ngraham added a comment.


  I don't object to your proposal per se, but I don't think it goes far enough 
to address the need here. Let me give you a specific example I'm familiar with:
  
  I recently submitted a patch (https://phabricator.kde.org/D13026) to fix a 
functional problem with Kate's Schema toolbar menu button 
(https://bugs.kde.org/show_bug.cgi?id=353747). Because of the bug that Hugo's 
patch here fixes, my Kate patch has the effect of removing the 
downward-pointing arrow, so the Schema button in Kate's toolbar will just be a 
single word, with no icon, and no downward-pointing arrow. It'll be just a 
piece of text awkwardly sitting there in the toolbar. In other words, without 
Hugo's patch here, fixing the functional problem (inappropriate requirement to 
click-and-hold) will cause a visual regression (the existing downward-pointing 
arrow disappears).
  
  We can of course later give the Schema an icon that you or someone else 
creates, but that's work for you (or Andreas, or someone else), and work for 
someone else to patch Kate to use the icon. Multiply this by the number of 
toolbar buttons affected by the issue throughout KDE software. We're talking 
about potentially a lot of icon design tasks and patches for apps to use them. 
And this burdens 3rd-party icon themes by increasing the number of icons they 
need to provide that will only be useful for users of the Breeze widget theme. 
And then what happens for people who use Breeze Icons or a compliant icon theme 
with a different widget theme that //does// draw downward-pointing arrows for 
menu buttons in toolbars? You'll have two downward-pointing arrows. Seems messy.
  
  Compare that complication and workload to just accepting this patch, which 
gives them all downward-pointing arrows in Breeze and resolves the issue 
without any icon design work or patches for individual apps or conflicts with 
other themes or extra work for 3rd-party icon themes. So to me it makes the 
most sense to handle this here in the theme rather than with an icon.
  
  If the objection to the arrow is that it's ugly, maybe we could come up with 
a prettier one?

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: zzag, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Andres Betts]

abetts added a comment.


  In D13064#267368 , @ngraham wrote:
  
  > In D13064#267358 , 
@hpereiradacosta wrote:
  >
  > > Should we also add a symbol on icons to say that they are non-dangerous ? 
(even if not a menu ?)
  >
  >
  > In fact, we already do signal danger by using red icons for potentially 
destructive actions.
  >
  > In D13064#267357 , @abetts wrote:
  >
  > > My thoughts come from a more foundational level. At ground level, to 
signal or not signal that the menu does or doesn't open a new window or a 
dropdown menu is irrelevant because the user doesn't care for what happens with 
the button prior to clicking it.
  >
  >
  > I think we've come to the real question: does the user click on the button 
even if they can't work out ahead of time what it does? If they do, then 
signaling isn't very important, because they will learn by doing. But if they 
don't, then it's important to provide as many signals as possible so we can 
coax them into feeling comfortable enough to click on it in the first place.
  >
  > This is part of the icon's job, after all: to signal what it will do if you 
click it. That's why we design our icons first and foremost to be clear and 
descriptive rather than abstract and artistic. In my mind, the 
downward-pointing arrow is just an extension of this logic.
  
  
  We don't have an icon similar to the one I suggested, but I can make one if 
you want?

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Nathaniel Graham]

ngraham added a comment.


  In D13064#267358 , 
@hpereiradacosta wrote:
  
  > Should we also add a symbol on icons to say that they are non-dangerous ? 
(even if not a menu ?)
  
  
  In fact, we already do signal danger by using red icons for potentially 
destructive actions.
  
  In D13064#267357 , @abetts wrote:
  
  > My thoughts come from a more foundational level. At ground level, to signal 
or not signal that the menu does or doesn't open a new window or a dropdown 
menu is irrelevant because the user doesn't care for what happens with the 
button prior to clicking it.
  
  
  I think we've come to the real question: does the user click on the button 
even if they can't work out ahead of time what it does? If they do, then 
signaling isn't very important, because they will learn by doing. But if they 
don't, then it's important to provide as many signals as possible so we can 
coax them into feeling comfortable enough to click on it in the first place.
  
  This is part of the icon's job, after all: to signal what it will do if you 
click it. That's why we design our icons first and foremost to be clear and 
descriptive rather than abstract and artistic. In my mind, the 
downward-pointing arrow is just an extension of this logic.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  In D13064#267357 , @abetts wrote:
  
  > In D13064#267356 , @ngraham 
wrote:
  >
  > > 'Fraid I gotta disagree with you on this one, @abetts. I think it's 
important to signal that these buttons will bring up a menu because without 
that, there is no way to distinguish it from an ordinary action button. It's 
the same reason why comboboxes have arrows rather than looking like a 
pushbutton.
  > >
  > > But there's a deeper reason. With the downward-pointing arrow, users are 
signaled that the button doesn't initiate an action (which may be unknown, 
non-undoable, possibly dangerous, etc), but rather displays a menu of textual, 
easy-to-understand options. In essence, the arrow says, "this > is safe, go 
ahead and click me even if you don't know what I might do". Without the arrow, 
fearful users might avoid clicking on the menu button because they don't know 
what it will do and nothing hints at them that the button brings up a benign 
menu rather than immediately executing a > If we must use the arrow, can there 
be a visual merge that is more consistent? Like this:
  >
  >
  > F5865549: order.png 
  >
  > Notice how the arrow butts into the icon keeping the overall rectangular 
shape the same. When we do icon + arrow visually we are making the button 
longer and seems disconnected.
  
  
  The suggestion looks nice (definitly better than current implementation). 
However there is really no easy way to implement this in a generic way, at the 
widget style level, in a fashion that will work with "all' icon, and "all" icon 
theme
  (try to do something that works with oxygen icons ...)
  
  On the other hand, if the idea is that we should design special icons for 
actions that actually open a menu, then I am all for it (and that would allow 
again to get rid of the arrow). As a matter of fact, this is exactly what 
happens for the "hamburger" icon. This one is designed to say "I am a menu" and 
first thing you want to do is to remove the arrow for those ...

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  I really don't understand the fear factor and unknown action argument. There 
are tooltips, possibly text alongside (or below icon), and the icon itself. 
Also, if you have to fear what an application might do to the point that you 
will only click on menus and not menu actions, I doubt you will achieve much. 
Should we also add a symbol on icons to say that they are non-dangerous ? (even 
if not a menu ?)

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Andres Betts]

abetts added a comment.


  In D13064#267356 , @ngraham wrote:
  
  > 'Fraid I gotta disagree with you on this one, @abetts. I think it's 
important to signal that these buttons will bring up a menu because without 
that, there is no way to distinguish it from an ordinary action button. It's 
the same reason why comboboxes have arrows rather than looking like a 
pushbutton.
  >
  > But there's a deeper reason. With the downward-pointing arrow, users are 
signaled that the button doesn't initiate an action (which may be unknown, 
non-undoable, possibly dangerous, etc), but rather displays a menu of textual, 
easy-to-understand options. In essence, the arrow says, "this is safe, go ahead 
and click me even if you don't know what I might do". Without the arrow, 
fearful users might avoid clicking on the menu button because they don't know 
what it will do and nothing hints at them that the button brings up a benign 
menu rather than immediately executing a possibly unknown action.
  
  
  This is a good idea, yes. It is another clue for the user to be able to find 
content and understand how the UI works. My thoughts come from a more 
foundational level. At ground level, to signal or not signal that the menu does 
or doesn't open a new window or a dropdown menu is irrelevant because the user 
doesn't care for what happens with the button prior to clicking it. The user 
cares for clicking the button, beyond that, it is us who control what they see 
next. Therefore, my thought is that while it is good to have clues, it is also 
irrelevant at the end of the day. I am ok with either option, but if we go with 
having the down arrow, then we "must" find a way that it looks pleasing, 
seamless and not a forced connection between two icons. Especially when we use 
line art in Plasma. If these icons were filled, this arrow would do well.
  
  If we must use the arrow, can there be a visual merge that is more 
consistent? Like this:
  
  F5865549: order.png 
  
  Notice how the arrow butts into the icon keeping the overall rectangular 
shape the same. When we do icon + arrow visually we are making the button 
longer and seems disconnected.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Nathaniel Graham]

ngraham added a comment.


  'Fraid I gotta disagree with you on this one, @abetts. I think it's important 
to signal that these buttons will bring up a menu because without that, there 
is no way to distinguish it from an ordinary action button. It's the same 
reason why comboboxes have arrows rather than looking like a pushbutton.
  
  But there's a deeper reason. With the downward-pointing arrow, users are 
signaled that the button doesn't initiate an action (which may be unknown, 
non-undoable, possibly dangerous, etc), but rather displays a menu of textual, 
easy-to-understand options. In essence, the arrow says, "this is safe, go ahead 
and click me even if you don't know what I might do". Without the arrow, 
fearful users might avoid clicking on the menu button because they don't know 
what it will do and nothing hints at them that the button brings up a benign 
menu rather than immediately executing a possibly unknown action.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Andres Betts]

abetts added a comment.


  In D13064#267117 , 
@hpereiradacosta wrote:
  
  > I am not particularly excited by the change, because on how it breaks the 
spacing between buttons in a toolbar.
  >  I am also not completely convinced that it is important to convey the 
information that a menu will open when you press on the button (because you 
usually learn that 'instantly' when pressing on it the first time), but since I 
have no other strong argument against re-adding this arrow, so be it.
  >  Any suggestion on improving the rendering is welcome, and no, one cannot 
move the arrow closer to the icon without actually overlapping with the icon. 
(breeze icons have a 2 pixels margins around their content, but this is not the 
case for all icon themes)
  
  
  I agree with you here Hugo. We "don't" have to signal every part of the 
actionable controls. Users will click it even if there wasn't any icon pointing 
in the down direction. I prefer it vanilla.

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  I am not particularly excited by the change, because on how it breaks the 
spacing between buttons in a toolbar.
  I am also not completely convinced that it is important to convey the 
information that a menu will open when you press on the button (because you 
usually learn that 'instantly' when pressing on it the first time), but since I 
have no other strong argument against re-adding this arrow, so be it.
  Any suggestion on improving the rendering is welcome, and no, one cannot move 
the arrow closer to the icon without actually overlapping with the icon. 
(breeze icons have a 2 pixels margins around their content, but this is not the 
case for all icon themes)

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta, ngraham, abetts
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta added a comment.


  How it looks for the sorting button in Open dialog:
  
  F5865249: Screenshot_20180523_172606.png 

  
  Gwenview "share" button:
  
  F5865251: Screenshot_20180523_172825.png 

  
  Dolphin hamburger button (without the property set)
  
  F5865253: Screenshot_20180523_172932.png 

  
  (when setting the propery "_kde_toolButton_noMenuArrow" on the button, it 
would look identical to the other toolbuttons)

REPOSITORY
  R31 Breeze

REVISION DETAIL
  https://phabricator.kde.org/D13064

To: hpereiradacosta
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta updated this revision to Diff 34723.
hpereiradacosta added a comment.


  Removed unrelated change

REPOSITORY
  R31 Breeze

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13064?vs=34720=34723

BRANCH
  master-toolbuttons

REVISION DETAIL
  https://phabricator.kde.org/D13064

AFFECTED FILES
  kstyle/breezepropertynames.cpp
  kstyle/breezepropertynames.h
  kstyle/breezestyle.cpp

To: hpereiradacosta
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup

[Hugo Pereira Da Costa]

hpereiradacosta created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
hpereiradacosta requested review of this revision.

REVISION SUMMARY
  As discussed in bug 344746 this helps identifying which toolbuttons 
  will trigger openning a menu when clicked
  
  A special property is introduced that can be set to either the toolbutton or 
the associated action
  in order to disable the rendering of this arrow.
  
  This is usefull for e.g. hamburger buttons, for which the arrow is 
superfluous. 
  The use of this property is left to the discretion of the calling application.
  
  CCBUG: 344746

REPOSITORY
  R31 Breeze

BRANCH
  master-toolbuttons

REVISION DETAIL
  https://phabricator.kde.org/D13064

AFFECTED FILES
  kstyle/breezepropertynames.cpp
  kstyle/breezepropertynames.h
  kstyle/breezestyle.cpp

To: hpereiradacosta
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart