Buttons with drop-down menu should have an arrow-down indicator. I think it was visible in older breeze (Qt) versions, not it's like on screenshots. It's present in the file dialog (options button) so I guess it's not related to Kexi. Although attaching Kexi screenshot as well. Reproducible: Always Expected Results: Drop-down visible as in oxygen for example.
Created attachment 91375 [details] Drop-down button in a file dialog
Created attachment 91376 [details] Drop-down button in a file dialog -- oxygen
Created attachment 91377 [details] Drop down in Kexi -- oxygen
Created attachment 91378 [details] Drop down in Kexi (the same code, just style changed)
(Qt 4 style 5.2.90)
not a bug, but a feature :) Admittingly, should have discussed it on the forum before. The rationale behind removing the arrow is that - it is "inline" and either overlaps with the icon in sometimes ugly ways (thats for the cosmetics), or artificially put asside of the icon which breaks spacing, and makes it undistinguisable from buttons with separate menu arrow (see below, and some undo/redo icons for some kde apps). - it is (now) hidden only for buttons for which the menu was "inline" and for which the popup is expected to open instantly. (as opposed to with a delay). Such buttons in fact behave like menu entries, and I don't see much added value to putting an arrow there, especially when it makes the icon look ugly, in the same way as there is no arrow added to menu entries, or no 'indicator' of any kind added to 'toggle' toolbuttons: you see an icon, you click on it, a menu pops up, (and you have no other possible interaction), you understand that this is a menu button. (in the same way as you do not discover a toggle button until you click on it). Does that make sense ? Also note that there are 'non -inline' menu tool buttons, such as in some undo-redo actions, where you can either click on the button, or on the arrow next to it, and for which too different actions are triggered) and for these of course, the arrow has not been removed. If you are not convinced, I'd like to have this discussed on the forum before reverting the change. Can you make a post (and ping me or link it here: I usually don't get notifications for new posts on the kde forum). Best, Hugo Hugo
Thanks for explaining the rationale. I think forum discussion is needed. Could you please start -- as the author of the change? Thx What if you alter size hint by the style so the arrow can fit? Delayed popup isn't a recommended element in my book. Another thing at usability level, buttons with nondelayed popups are nondestructive. Without any indication it's hard to tell if the button is destructive or not. This translates to user put in a non easy situation.
BTW, if you look at Kexi's screenshot. I am almost sure the "Table" text could be perceived as a label. Result: low discoverability of important functions.
Created attachment 91379 [details] Help drop down in Kexi; there's enough space to display the indicator. Now it looks just like an "info" icon.
Look how the Help menu looked before: http://kexi-project.org/pics/2.9/kexi-2.9-tableview.png
... your shooting comments too rapidly for me to answer. In any case, the last screenshot you sent is precisely some of the reasons why I removed the arrow. I have no clue, looking at it, to what it is attached, whether it belongs to the editor, to the 'information' icon next to it (I thought that help icon was actually a different one), whether I should click on the arrow, on the icon, or on the editor, etc. So: not much value added, IMHO For the other screenshot (the table), that's a kexi specificity.
Created attachment 91380 [details] In cleanlooks it's nicely positioned
... not so nice here though: http://wstaw.org/m/2015/03/02/plasma-desktopBz7244.png (cleanlooks also) and there are worse cases.
@Comment13 If we could subtract a circle (or rectangle) from the icon and then put arrow overlay there... Like the "+" subtracts a part of the "tab" icon in the "tab-new" icon.
Hello Hugo. What's new with this? Not even confirmed? Still the same issue in Kexi.
Arrows are still visible for toolbuttons with menus that use long-press (examples: "Schema" toolbar button in Kate and "Tools" toolbar button in Okular), but not those that show their menus with a single regular click (example: "Create New" toolbar button in Dolphin). This is somewhat odd. Since I'm not aware of any usability issues stemming from showing the arrow for long-press menu buttons, my recommendation would be to add them back to regular menu buttons too. I think it's important for buttons which open menus to visually telegraph this somehow. There's a reason why the combobox exists looks the way it does rather than looking identical to any other button. It's a usability thing.
I wonder if we can't find some compromise here. Here's what I might propose: - "Hamburger menu" button: no change; no arrow. Rationale: this button is commonly understood to always display a menu. I don't like this kind of button, but if we have to have it (and apparently we do), it works best with no arrow. - Toolbutton with a menu that opens with long-click: no change; small arrow. Rationale: the small and de-emphasized arrow on this button does a good job of illustrating that there's more here, but that the primary interaction is via single-click and the menu is a secondary thing. - Toolbutton with a menu that opens with single-click: A more visually prominent arrow that's horizontally centered. Rationale: the only point of this button is to open a menu. It should show its intent, like other buttons that display menus--which all have downward-pointing arrows to indicate it (Spectacle in 18.04 has several for comparison purposes).
Hello Nate, Two points: - detecting hamburger buttons from the style point of view will be quite difficult - Some mockups on how the menu only toobuttons should look (by you or any of the vdg) would be appreaciated. Also included cases where button text is shown bellow the icon, or next to the icon. Again, the reason behind hiding this arrow for buttons for which the _only_ choice is to open a menu, is only about esthetics. So far we do not have a nice design for such butttons plus arrow, that match all text positions, all icon themes, that do not overlap the icon and makes it clear to which button the arrow correspond, etc. Any proposed design that fixes the above will be gladly adopted I think.
I agree the current situation is not ideal in lots of our UIs regarding the discoverability of the menu. If users are looking for a menu, they'll likely just skip over anything which looks like a plain button. Having some kind of visual indication would help them out tremendously. For menu entries and pushbuttons the difference between a menu/dialog and an immediate action is also already visible, either via the arrow, or via the "..." text. The same reasoning applies to toolbutton actions vs toolbutton menus. --- We already have QToolButtons with an arrow on the right side for MenuButtonPopup mode. Upon hover, the icon will get a frame, to indicate clicking on the icon and on the arrow will result in different actions. Here is an idea: For InstantPopup mode, we could reuse the visual language and also add the arrow on the right side. The difference could be in the hovering, where now the frame could span both icon and arrow, to indicate clicking on either will result in the same action. (Incidentally, this is exactly how some buttons in Windows Explorer already work, so users would already be somewhat familiar with the visual language!) @Hugo: As far as I can see, this would solve most of your concerns. Or do you prefer a wider VDG discussion? Please let us know ;)
Here is how Thunderbird is rendering both button styles: https://phabricator.kde.org/F5817563
(In reply to Henrik Fehlauer from comment #20) > Here is how Thunderbird is rendering both button styles: > > https://phabricator.kde.org/F5817563 Thanks for the screenshot. In fact it illustrates exactly my issue with these arrows. Looking at the first too buttons and without mouse over, I do not know to which button the arrow belong (and in fact intuitively I would have associated the first arrow to the wrong button because of the separator. When there is no separator (like for the last button), it is even worse. This is the issue I'm trying to raise when I mention the lack of a good design for such arrows.
(In reply to Hugo Pereira Da Costa from comment #21) > (In reply to Henrik Fehlauer from comment #20) > > Here is how Thunderbird is rendering both button styles: > > > > https://phabricator.kde.org/F5817563 > > Thanks for the screenshot. > In fact it illustrates exactly my issue with these arrows. Looking at the > first too buttons and without mouse over, I do not know to which button the > arrow belong (and in fact intuitively I would have associated the first > arrow to the wrong button because of the separator. > When there is no separator (like for the last button), it is even worse. > > This is the issue I'm trying to raise when I mention the lack of a good > design for such arrows. If you folks think this is not an issue I sure can re-introduce the arrow. (for _all_ buttons, hamburger or not, since the style do not know about those)
> I do not know to which button the arrow belong Hm, there is some truth to this point, so I guess it's a matter balancing differing requirements. I'd tend to go for showing arrows, but let's wait what Nate has to say. If we went for arrows on the side, maybe the horizontal spacing should change then too for those buttons, i.e. they would not be square anymore, but a rectangle due to increasing the margin on the right side. At least for me the spacing in Thunderbird makes it pretty clear what button an arrow belongs to (the video is a bit of an edge case due to the toggling, without toggling it looks better; and the toggling itself shows also pretty clearly that the arrow belongs to another button). Lastly this is also a question of habit. I think users will learn pretty quickly that arrows always belong to the button on the left.
I don't think the Thunderbird example is all that unclear--at least not to my wife and mother, who both use Thunderbird daily and whom I often use as barometers of what "average users" consider easy or difficult (one is a retired college professor in the humanities, and the other is an artist). We could make it more obvious which button the arrow belongs to by moving it a bit closer to the button's icon or text. Alas, this is always going to be an inherent issue with borderless toolbuttons, and it's the price we pay for having chosen to use them instead of always showing the button border. I find it quite telling that the issue goes away entirely for buttons with borders, which tells me that hiding the buttons amounts to working around a limitation of another decision we've made. IMHO in these cases, if the original decision can't be revisited, we need to make extra effort to satisfactorily resolve the issue stemming from it, rather than giving up and simply replacing it with a *different* issue, which is what's happened after we removed the arrows. So +1 for returning the arrows, but with some tweaks to improve the ease of determining which button they're attached to.
See https://phabricator.kde.org/D13064
Git commit 3bc6636cf6b506908c29bf92842d8b7f773ee00c by Arjen Hiemstra. Committed on 11/08/2020 at 09:41. Pushed by ahiemstra into branch 'master'. Draw arrows on toolbuttons with menus and no popup delay This changes ToolButtons to behave similar to PushButtons, so they both draw an downward pointing arrow when they have a menu. M +76 -23 kstyle/breezestyle.cpp https://invent.kde.org/plasma/breeze/commit/3bc6636cf6b506908c29bf92842d8b7f773ee00c