How it looks for the sorting button in Open dialog:

Gwenview "share" button:

Dolphin hamburger button (without the property set)

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

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)

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.

'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.

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:

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.

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 ?)

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:

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 ...

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.

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?

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?

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:

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:

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:

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.

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 from 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.