Bug 384514 - Toolbar Segmented Controls do not visually communicate their grouping
Summary: Toolbar Segmented Controls do not visually communicate their grouping
Status: RESOLVED NOT A BUG
Alias: None
Product: Breeze
Classification: Plasma
Component: QStyle (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-09 03:14 UTC by Nate Graham
Modified: 2023-11-19 00:48 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
nate: Usability+


Attachments
What the user sees (238.25 KB, image/png)
2017-09-09 03:15 UTC, Nate Graham
Details
What the buttons actually do (246.27 KB, image/png)
2017-09-09 03:15 UTC, Nate Graham
Details
Idea for improvement (238.35 KB, image/png)
2017-09-09 03:26 UTC, Nate Graham
Details
Real segmented control elsewhere in Gwenview (2.62 KB, image/png)
2017-09-09 13:23 UTC, Nate Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2017-09-09 03:14:39 UTC
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.
Comment 1 Nate Graham 2017-09-09 03:15:06 UTC
Created attachment 107768 [details]
What the user sees
Comment 2 Nate Graham 2017-09-09 03:15:27 UTC
Created attachment 107769 [details]
What the buttons actually do
Comment 3 Nate Graham 2017-09-09 03:26:02 UTC
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.
Comment 4 Roman Gilg 2017-09-09 10:15:03 UTC
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.
Comment 5 Nate Graham 2017-09-09 13:23:50 UTC
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.
Comment 6 Hugo Pereira Da Costa 2017-09-12 11:01:52 UTC
(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
Comment 7 Nate Graham 2017-09-13 05:00:10 UTC
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.
Comment 8 Hugo Pereira Da Costa 2018-07-28 09:30:10 UTC
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