GNOME Decides to Ditch Drawings
One of the most striking features of any desktop environment is its selection of icons. While wallpapers and window decorations hold a larger stage, it is the bright, colorful icons that draw ones attention and speed up the process of finding what one is looking for. The myriad of available icon themes may find themselves feeling a bit lonely in the near future, however, as the GNOME Art Team has decided that — at least some of them — will face the firing squad.
According to a blog post by Andreas Nilsson of the GNOME Art Team, a new policy on icon use has been adopted for future versions. In addition to adding larger icons for certain locales, the team has decided that the default value of the gtk-menu-images property in future GNOME releases will be changed to false, eliminating most of the icons used in menus. (This would include those used to represent "Open," "Save," and other similar dialogues.) The team feels it will produce a "visually more attractive default and that it will result in a cleaner and more efficient interface."
Before the torches and pitchforks emerge, however, there are exceptions. GNOME isn't to be completely icon-less — exceptions to the rule will include icons that depict a "dynamic object," including applications, files, bookmarks, and devices. Application developers will also have the option to override the default — it is Open Source, after all — using the gtk-image-menu-item-set-always-show-image property.
It is currently unclear whether users will also be given the opportunity to reverse this setting if they prefer the icons — a cursory review of the gconf-editor utility does not immediately reveal an option to alter the property, and Nilsson's blog post does not address the issue specifically. Although the note "and you can always change it back" appears in parenthesis after his comment about a "cleaner and more efficient interface," it is not immediately obvious whether this is directed towards users, or refers to the ability of developers to utilize gtk-image-menu-item-set-always-show-image. One expects that clarification on this point will be forthcoming as users begin to question the change.
Nilsson notes that "[g]etting rid of things (or changing defaults for that matter) is always tricky," saying that "the initial reaction from people used to the old behavior is that nothing of value gets added." This would seem to be a spot-on assessment, and is likely to be a fairly accurate prediction of the response that is to come. As support for the change, Nilsson cites the additional mental "processing" required by the use of both icons and text, as well as statistics showing the average human "skimming speed" to be in the range of 400 - 700 words per minute. There is acknowledgment, however, that icons, particularly by virtue of color, speed recognition significantly.
Without donning our Carnac the Magnificent attire, we predict the GNOME Art Team will hear more than they ever wanted to about the change. Without question, some will skip the "menu item" point entirely and jump directly to accusing the team of unilaterally removing all icons from GNOME. Others have already begun to question the decision to change the default, advocating for an opt-in approach instead, allowing users to remove the icons by preference dialog rather than changing the default behavior.
There does appear to be a certain logic to the idea of opt-in. Without resorting to stereotypes, it does seem that in similar discussions, it has been the more experienced users who prefer text-based interfaces — not command line v. GUI, but in areas like menus — while newer users have tended to favor a more graphical approach. On a practical level, one might assume that experienced users would be more likely than those brand new to Linux to know how to change the setting, particularly if the only way to effect it is through gconf-editor. There is likely a whole debate to be had — perhaps re-had — over efficiency v. user friendliness when making this type of choice.
Nilsson described the current situation as "some items have them, and some don’t," saying the disparity "is because no artist had time to draw it, or because the action is too complex to convey in a small icon, or both." "[H]and to heart," he says, "that’s not a really good guideline."
In the end — again consulting our crystal ball — we predict that while the default may change, the status quo will not. As it stands, developers who don't want icons, or aren't concerned either way, don't include any, and as a result, there are no icons. Those who want their application to have icons take the extra step and provide icons. If the default is changed, this will still be the case: those who don't want icons will continue not include any, just as it was before, and those who do want them will take the extra step to set gtk-image-menu-item-set-always-show-image.
When the dust settles — and with any luck, there won't be much — the end result will be that everyone is still standing where they were — just covered in dust.
Justin Ryan is a Contributing Editor for Linux Journal.
|PasswordPing Ltd.'s Exposed Password and Credentials API Service||Apr 28, 2017|
|Graph Any Data with Cacti!||Apr 27, 2017|
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
- Graph Any Data with Cacti!
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- PasswordPing Ltd.'s Exposed Password and Credentials API Service
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- IGEL Universal Desktop Converter
- Server Technology's HDOT Alt-Phase Switched POPS PDU