There are a few usability problems with toolbar buttons in Breeze stemming from the fact that multiple types of controls have the same visual appearance. For example, consider this standard toolbar in Gwenview. Here's what the user sees: https://i.imgur.com/Nu3WieQ.png The darkened background acts as a visual cue that that the "View" button has a toggle-able state. But the rest all look like regular pushbuttons. However, here's what they actually are: https://i.imgur.com/eAVm9Wk.png You can see that the View toggle button is not actually a toggle button at all but rather part of a segmented control with browse button, expressing the idea that only one state can be active at once: Browse or View. But this isn't obvious because those two buttons aren't grouped together in any wya that suggests that only one state at a time is active. Meanwhile, the Sidebar button is actually a toggle button rather than a regular pushbutton, even it looks the same as the Full Screen button next to it, which is a regular pushbutton. We should consider doing the following: - Tweak the un-toggled state of toggle buttons to differentiate them from pushbuttons - Visually connect the buttons together in segmented controls to differentiate them from toggle buttons and pushbuttons For reference, here's the Apple HIG on the matter: - Segmented controls: https://developer.apple.com/macos/human-interface-guidelines/selectors/segmented-controls/ - Pushbuttons: https://developer.apple.com/macos/human-interface-guidelines/buttons/push-buttons/ Notice that these UI elements can be easily distinguished from one another visually.
Created attachment 107768 [details] What the user sees
Created attachment 107769 [details] What the buttons actually do
Created attachment 107770 [details] Idea for improvement Random idea: draw a 1px line around the outline for toggle buttons and segmented controls: https://i.imgur.com/54IcN5F.png Just an idea, feel free to ignore.
Our toolbar buttons are arbitrarily placeable. The "segmented controls" are in reality two separate toggle buttons. But when NOT being in active state a toggle button shouldn't be visually different from a push button, since on its own its type of action is no different than that of a push button (triggering something). The right way under the constraints of toolbar buttons being arbitrarily placeable is to separate "segmented controls" from other ones by using separators. Indeed my Gwenview does it this way in the default toolbar configuration. But it's not optimal since it can look somewhat weird with many separators. Maybe we could think of a mechanism to check if toggle buttons with mutually exclusive functionality are sitting next to each other and in this case paint your proposed frame around them instead of having the app developers/user use separators all other the place. Would be a bigger change in code though and I don't know if it's possible.
Created attachment 107772 [details] Real segmented control elsewhere in Gwenview Since making un-pushed toggle buttons visually distinct from pushbuttons appears to be more controversial, I'll drop that for now and focus on segmented controls. Not having a dedicated segmented control concept/UI element is a major problem. But I see that in Gwenview, we actually do use a button-based segmented control elsewhere: https://i.imgur.com/pySdLn0.png Other than the padding issues with text on the middle button, this is ideal, and clearly communicates at-a-glance the concept that only one of those three states can be chosen at once. We might consider using this instead, or even standardizing it.
(In reply to Nate Graham from comment #5) > Created attachment 107772 [details] > Real segmented control elsewhere in Gwenview > > Since making un-pushed toggle buttons visually distinct from pushbuttons > appears to be more controversial, I'll drop that for now and focus on > segmented controls. Not having a dedicated segmented control concept/UI > element is a major problem. But I see that in Gwenview, we actually do use a > button-based segmented control elsewhere: https://i.imgur.com/pySdLn0.png > > Other than the padding issues with text on the middle button, this is ideal, > and clearly communicates at-a-glance the concept that only one of those > three states can be chosen at once. We might consider using this instead, or > even standardizing it. as far as I know this is a gwenview specific custom widget. one could move it "upstream" in widgetsAddon or somethign like that, fix the padding issues, and leave it to applicatiosn to use it or not. any heuristic at the style level to do the rendering directly will be a kludge and likely bound to fail
FWIW here is the upstream Qt bug report asking for Segmented Controls: https://bugreports.qt.io/browse/QTBUG-51008 In the meantime, it would very much be nice to upstream the custom widget from Gwenview.
Closing as invalid. Upstreaming widgets is not a breeze issue. Breeze itself has no mean of resolving this issue since there is no way to tell it that toolbar buttons should be grouped