After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 706100 - Please let me have toolbar-style back.
Please let me have toolbar-style back.
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkToolbar
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-08-16 06:18 UTC by Adam Williamson
Modified: 2017-08-30 14:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Williamson 2013-08-16 06:18:24 UTC
I hate to be one of those people whining about choice, but https://mail.gnome.org/archives/commits-list/2013-July/msg02297.html is just _brutal_.

I can't find the reference any more, but setting it to 'text' has been something I've done just about first thing on any desktop I've used in the last seven years or so, since I first picked the tip up from planet.gnome.org . I can't find that post any more, but whoever wrote it made a very cogent argument that you usually have no damn idea what whatever clever icon the app you're using means, but you're very rarely going to have a problem understanding its label.

Ever since this was 'deprecated' I've been wasting time staring at toolbars trying to figure out what icons mean, and it's a pain in the ass. I'd really like not to have to deal with this forever...
Comment 1 André Klapper 2013-08-16 10:00:49 UTC
Elaborating on the incentive for such design decisions, plus linking to data of studies, both in the actual commit messge, would be very welcome indeed.
Comment 2 Adam Williamson 2013-08-16 16:18:38 UTC
If anything, I'd argue that if you're going to take out the choice then fine, but just set it to 'text' for everyone, not 'both-horiz'. It is unquestionably functionally more useful, and I for one find it looks better: all those icons are just visual diarrhea.
Comment 3 Adam Williamson 2013-08-16 16:25:30 UTC
http://uxmyths.com/post/715009009/myth-icons-enhance-usability is one reference I found, not the original though. Still can't find that original post that taught me about the setting in the first place :/ ah well.
Comment 4 Adam Williamson 2013-08-17 07:07:07 UTC
example: the icon for "details" in virt-manager is a light bulb. Because...because...er...
Comment 5 Adam Williamson 2013-08-22 17:03:22 UTC
More examples: most of the icons in Evolution. I don't think a single one in the 'new appointment / edit appointment' window is self-explanatory. Except possibly 'Print'.
Comment 6 Emmanuele Bassi (:ebassi) 2017-08-30 14:40:49 UTC
The HIG specifies that icons should only be used in toolbar when their meaning is common knowledge and immediately recognisable, and to default to text if that's at all possible:

  https://developer.gnome.org/hig/stable/icons-and-artwork.html.en

'''
There are many situations when it is necessary to decide between using an icon and a text label, particularly for buttons. Icons have the advantage of being smaller, and not requiring translation. At the same time, the incorrect use of an icon can make your interface hard - or even impossible - to understand.

Only use icons whose meaning is commonly recognized. If a commonly recognized icon is not available, it might be better to use a text label instead.

Convention establishes which icons will be recognized. If you are in doubt, stick to icons which are frequently used in other applications.

Consider which icons will be meaningful in the specific context of your application - users of specialist tools will often be familiar with domain-specific symbols.
'''

Instead of making this a toolkit option and break application UI onto unsuspecting developers, applications need to be fixed to conform to this basic bit of UI common sense.

If an application is abusing icons all over the place, please: file a bug against it and point the maintainers to the HIG.