GNOME Bugzilla – Bug 107781
Give up on homogeneous items when toolbar needs space
Last modified: 2018-02-10 04:34:30 UTC
If i remember correctly, I believe that the usability team last recommended that toolbar buttons have a minimum size but not be homogeneous, so that the rare toolbar item with a long label does not cause all other toolbar items to appear unnaturally wide.
Currently you can set each item in the toolbar to homogeneous or non-homogeneous. By default toolbar buttons are homogeneous. Can you give a link to the mailing list discussion where this was fleshed out? Personally, I deal with long toolbar labels by turning them off -- they are simply meant to be shortcuts for items in the menus, so the icon is generally enough to match up its meaning (stock icons help a lot here too).
I'm not sure if there was a mailing list conversation (there may be an old bug though), i just have a vague recollection of a discussion with seth and calum a while ago. I'll bring this up with them. I just wanted to raise the issue prior to egg being merged into gtk making a change all the more harder. Also turning off labels is not an option, in particular text+icons makes toolbars much faster to use (as noted, by seth, tog etc.) http://mail.gnome.org/archives/usability/2002-August/msg00056.html http://www.asktog.com/columns/022DesignedToGiveFitts.html
I am not sure about the desirability of these labels either. Given that they should not be "necessary" to the use of the icons, perhaps the default behavior should be to size toobar items based on the icon size instead of the label size? It would cause overly-long labels to get clipped, but this would help discourage the use of extra-long-icon-labels-that-cause-everything-else-to-break-unless-buttons-aren't homogeneous
ccing marco for ephy specific input on this issue (since he knows much more than I).
bill: The use of labels has been shown by apple to increase the speed by which mouse users can use toolbar icons considerably, see both the above links.
Hm, I didn't know that Apple had done research explicitly on toolbar labels vs. no toolbar labels, but larger targets *are* much easier to click, especially when moving from a distance (which you often will be with toolbar items). Since toolbar items are, theoretically, items that you want to access really quickly and frequently, it makes sense to make them easy to hit.
Moving to new toolbar component
*** Bug 112192 has been marked as a duplicate of this bug. ***
Bug 91344 is another old bug filed by me against libbonoboui about the same issue. Labels might be arguable but if we can agree that we want them (and I think we do, considering that they were made the GNOME default?), then this definately should be fixed before it gets into Gtk. I would suggest to use the height of the button as its minimum width, because then you get a nice square button by default to click at and there are no hardcoded values involved.
This is a gtk+ bug now
Not really sure what's the suggested action. Is it to make buttons added through the new API non-homogeneous by default?
The action I'd propose is: - Add an internal maximum width, beyond which buttons do not participate in the homogeneous game. This means buttons with very long labels will not force other buttons to become long. - Leave buttons homogeneous by default. I don't think too-narrow buttons is an issue as long as homogeneous behavior is the default. If people agree, then this bug can be moved to the 2.4 milestone.
Yeah that is what i basically had in mind.
*** Bug 75068 has been marked as a duplicate of this bug. ***
I have committed the change below, but I'll retitle this bug and leave it open, because I think it is possible to do better: The problem with too-wide buttons is only relevant when there is not enough space on the toolbar, so we should only give up on homogeneous buttons only in that case. However, when the toolbar needs space, it should always try making the widest homogeneous item non-homogeneous, before relegating items to the overflow menu, no matter how wide the widest item actually is. Fri Aug 29 20:32:07 2003 Soeren Sandmann <sandmann@daimi.au.dk> * gtk/gtktoolbar.c: Only treat buttons as homogeneous when they are narrower than 13 time the estimated character width of the font. (#107781, David Bordoley)
The algorithm for doing this is simple enough: sort the homogeneous items according to requested width while (extra space) add enough extra space to those items that currently have the smallest width, that they become as wide as the smallest item that is wider than the set of items with the smallest width. My concern is about breaking motor memory; doing this will cause items to move around much more than they do currently. The question is: Which is worse - relegating items to the overflow menu - making items narrower (making them move around) in order to make room for more items Or, are both options bad enough that turning homogeneous behavior off altogether is worthwhile? A comment from the usability team would be appreciated.
Well... I'm not positive that non-homogenous buttons are only relevant when overflow is needed, but for now I don't think that's an important issue and we can use it only for overflow (which is the most important case, certainely). I don't believe substantial motor memory is built-up for toolbar items, especially because the toolbar button width varies a lot across applications (with homogenous turned on) even for the most standard items like "Open" and "Save" (which are the only ones you'd expect to build up muscle memory for anyway). So I would say relegating items to the overflow menu is worse.
re: minimum size for aesthetic reasons I'd expect the minimum width to be the same as the height even if the button label is very short (eg cut/copy).
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.