The Gnome interface guidelines don't mention when items should have icons, with one exception: <http://library.gnome.org/devel/hig-book/stable/menus-standard.html.en#menu-standard-bookmarks> says "Show icons for bookmark entries on the Bookmarks menu that indicate the type of the bookmark, even if the user has globally turned off icons for other menu items on the desktop." However, neither Epiphany nor Nautilus follow the second part of this guideline. Is it even *possible* to follow it? If not, then turning off menus_have_icons by default will lose the baby along with the bathwater.

In any case, I do not think the menus_have_icons option should exist. Whether a menu item is faster to use with an icon depends much more on the item than on the user. I think the guideline should be: A menu item should have an icon only if it represents a dynamic object such as an application, file, device, or user, or if it makes the items in that menu segment very much more recognizable. (For examples of the latter, see
<http://mail.gnome.org/archives/usability/2006-February/msg00000.html>.)

I guess there are two ways to get from here to there. One is to adjust GTK so that it ignores all icons currently specified, but accepts a new use_this_icon_and_yes_it_really_is_appropriate parameter. The other way is to publish and promote the above guideline and then take a cleaver to applications, ripping out most (but not all) of their menu item icons.

Matthew: I agree to what you're saying, because we certainly need some sort of guidance. Currently applications tend to have icons for everything in their menus, except for the cases where the artist said "no, I don't have time to draw that". I still have some questions though.
Does save-as that use a hard drive + arrow count as object, or does that count as action? (I guess the latter, just want clarification)
Do you mean file like in the Open Recent menu in GIMP, or something else?
I guess what I'm asking for is examples.

Anyway, +1 from me

Yes, "Save As" is an action, not an object, therefore no icon.

In Gimp's "Open Recent" submenu, all items would have icons except "Document History".

In Epiphany's "Bookmarks" menu, all items would have icons except "Add Bookmark", "Edit Bookmarks", and "Nearby Sites".

In Nautilus's "Places" menu, all items would have icons except "Search for Files", "Add Bookmark", and "Edit Bookmarks".

In Rhythmbox, the only menu items with icons would be any already-existing playlists in the "Edit" > "Add to Playlist" submenu.

Guys, has anyone of you actually tried to use the desktop with menus_have_icons=false? :/

Ok, three cases here:

1.) The applications menu shows no app icons. Bummer. This is bad, bad, bad. Trying to start some apps makes me feel like a first-time user :(

2.) Context menus: harder to use without icons IMHO. I have to read the whole thing to find stuff like copy/paste. Ok, most of the time I use the keyboard for those things anyway. Plus, I could use the toolbar for those same actions in most apps.

3.) Menus: same as for the context menus. Maybe my problem is that I tend to use the menu even if toolbar buttons exist for stuff like redo/undo. Generally I agree that less is more here: masses of icons don't help at all, but making some actions/objects stand out is a good thing IMHO.

Example: gconf-editor's file menu. Three "new xyz window" with the gtk-new icon, plus close, plus quit.
Solution a) get rid of all icons because the new window items are arguably not used much and most people close the window using the window [x] button.
Solution b) only use one characteristic icon per "group". So, the first "new xyz window" would actually show a fitting icon (window-new) and either close or quit could have one, too. Another example would be giving "Save" an icon but not the variants normally found right below ("Save As", "Save Copy" etc) or "Search" (vs "Search and replace", "Search next", etc).

The second solution would be a "lighter" change but probably not easy to achieve in the current community. We could try, though...

The first solution is most likely NOT what the majority of users wants, even if the "designers" like it. OSX was listed as a reason... well, first, not everything in OSX is without flaw (very few things are, actually). Second, the usage of the menu in OSX does not seem to be a 1st class thing anyway. I asked a Mac guy once, wondering if it wasn't a problem to move the mouse up to the top menu all the time. Answer: "I rarely have to use it".

So, if apps were designed to work just fine even without the menu bar we certainly would not need any icons. In that case, moving the menu bar to a central place a la OSX even makes a lot of sense. Another example would be Google's Chrome: the "menu" is reduced to a popup from one toolbar button. The GUI is much less complex because of this, has a cleaner look and yet you don't really miss any functionality. 
But wait... isn't it the HIG which asks for menus on all main windows? We had this discussion for Cheese and Tomboy (search window) IIRC... Two examples where we could do better without any menu but can't because we "want" to follow the HIG. Of cause this leads to useless menu entries because noone likes menus with just 1-2 entries... :(

So, a +/-1 from me. I agree the goal is noble but just flipping the switch any leaving the usage (and app design) paradigms as-is will not help and only enrage users.

As a user, I have to politely yet strongly disagree with the reporter of this bug. Icons are visual clues that your mind memorizes much faster than words. I use icons to select menus without even thinking about it.

The same goes for applications. Menus without icons would be a poor default. Just because OS X and Windows do this does not mean we should follow suit.

Here is a question for you, "Does having icons in the menus by default hurt anything or have any negative performance impact?". No I'm not talking about microbenchmarks. Does having icons in the menus have any user visible negative impact? If the answer is no, you are changing defaults just to change them. That is not a good idea.

You guys must be joking right? You really want GNOME to look like this: http://jeff.ecchi.ca/public/557469.ogv ?

Have you tried to use complex apps like Evolution, AbiWord/OpenOffice without menu icons as cues of item relevancy? While we're blindly copying Apple's design, why don't we have a global menu bar and dock as the canonical default then?

Jeff: Our current approach is "put icons before every menu item possible"
Garrett's Industrial Firefox theme was one of the few occasions where we
actually managed to do that, with a somewhat um, interesting result.
http://gnomefx.mozdev.org/blue-file.png

From a graphics design point of view, having a look with less clutter makes the
system look nicer and cleaner. I don't think it would mean any loss in speed,
as the eye recognize the individual words as shapes, rather than identifying
every single character.

"Readers may use morpheme, semantics, syntax and context cues to identify the
meaning of unknown words. Readers integrate the words they have read into their
existing framework of knowledge or schema (schemata theory)."
http://en.wikipedia.org/wiki/Reading_(process)

Words are icons too, just better. :)

I'm not saying we should be having icons for all menu items either. I'd like to think that the HIG should have a section on "have icons only to prioritize certain menu items".

My 2 cents: when I use menus in apps like evolution with the default gnome icon theme, my eye is automatically cued to colors and shapes. I could read all the stuff in the View menu, but then the presence of icons near certain frequently used items *does* help by drawing my attention to them, thus enhancing the choice/visual scanning process. I can very quickly find the "Load images" menu item, for example.

Indeed, having icons for every single menu item would be counterproductive on a usability standpoint, on the same grounds as having 10 tabs in a dialog or having 30 buttons in a toolbar reduce usability. I guess this could be more of a task for a revision of the HIG.

(In reply to comment #8)
> [...] when I use menus in apps like evolution with the default gnome icon
> theme, my eye is automatically cued to colors and shapes [...]

Perfect example. Actually, a counter example for me :)

Let's see... File->New.. ouch. There's 15 entries using 13 different icons (*). No real structure and bad metaphors. Removing the icons and actually have some structure would make it much easier to use. The way it is now it is just overwhelming. Other useless icons are "import" and "apply filters".

In all those years I think I have used exactly *two* menu items in evolution: Preferences and the Filter manager.


(*) please add "I must not use the same icon for different things" to the guide. Another example of this: Evo composer window, "Save" and "Save Draft"...

Michael on #4:
The application menu would have icons in it, according to Matthews recommended guidelines in #1.

Meanwhile, Mozilla wonders what to do with Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=465669

Andreas: only that it does not atm :) I'm not even sure if there would be a nice and easy "fix" for this.

@Michael, sure there is. Close the bug with WONTFIX :)

Well having a certain amount of icons certainly helps *me* to find the stuff I need in some apps (and I know others rely on it, too) but at the end of the day, those menu icons still seem to be a bad excuse for not fixing the UI (uncluttering the menus, making features more accessible) in the first place.

The problem is illustrated very well in Jensen Harris' presentation¹ about the evolution of the Office UI (seriously, take the time and watch it). I'm not saying we should introduce ribbons but I think we need to take a look at the bigger picture and actually solve the problems instead of working around, one way or another.

[1] http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

I agree with Jeff Schroeder (comment 12) in that merely setting menus_have_icons=false by default, and doing nothing else, would not make anyone happy and therefore should not be done. I think this bug report is a bit confused because it started with a proposed solution rather than with a problem.

We might state the actual problem, based on the discussion so far, like this:
------------
Some designers involved in Gnome, or software that integrates with Gnome, believe that it uses too many icons in menus. Examples:
http://www.tigert.com/archives/2005/09/15/ive-created-a-monster/
https://bugzilla.mozilla.org/show_bug.cgi?id=465669
http://mpt.net.nz/archive/2005/04/11/ubuntu#appearance (item 3)

The designers have identified these problems with current practice:
1. In most popular Gnome applications, most menu items have icons, but some do not — either because the artists have not had time to draw it, or because the idea is too complex to convey in a small icon, or both. Neither of these reasons are relevant to users, who are left wondering whether the presence or absence of an icon means anything in particular.
2. The visual noise from the icons may slow people down in finding a particular item, rather than speeding them up as intended. (Especially when a menu contains consecutive similar items, such as “Save” and “Save As”, or “Find” and “Find Next”.)
3. The clutter from the icons may decrease people’s perception of the elegance of the interface, and therefore decrease their satisfaction.
4. A menu heavily laden with icons opens more slowly.

The presence of icons is currently controlled by the /desktop/gnome/interface/menus_have_icons gconf key, which defaults to true. Setting it to false removes icons from all menus, including the Applications menu and Epiphany’s Bookmarks menu. There is widespread agreement that the Applications menu (at least) should continue to have icons by default, so changing the default value of the gconf key alone would be undesirable. (And doing so probably would worsen problem #1 over time for users who inherited or changed the value to true, because artists would further deprioritize menu icon work.)
------------

Perhaps this should become a new bug report, so a comprehensive solution can be discussed involving changes to the HIGs, changes to GTK, and changes to applications.

Meanwhile, I repeat my question from comment 1: Is it technically feasible for an application to follow the HIG and "Show icons for bookmark entries on the Bookmarks menu ... even if the user has globally turned off icons for other menu items on the desktop"? The answer to this determines whether changing the default value of the gconf key would be *part* of the solution to the problem.

Nice summary, with which I agree. Getting apps maker to exerce voluntary ("zen") restraint on which items to emphasize with icons, however, will be quite more work on their part. I mean, this would be as difficult a dilemma as going through the toolbar items to choose which one have the attribute is_important (that makes the label show when in compact mode). There's a natural tendency for app makers to believe that pretty much anything is important in the featureset.

On a tangent, you may also want to look at bug #561521, which is a visible consequence of not having (enough) icons on a menu: there is no default padding, making the menu look awkwardly out of place compared to other menus that contain icons, checkboxes or option groups.

Yes, I find myself cringing at the sight of menus that have no icons, /essentially/ because of this cosmetic reason. If menus had padding, I perhaps wouldn't mind "so much" the loss of icons.

> Is it technically feasible for
> an application to follow the HIG and "Show icons for bookmark entries on the
> Bookmarks menu ... even if the user has globally turned off icons for other
> menu items on the desktop"? The answer to this determines whether changing the
> default value of the gconf key would be *part* of the solution to the problem.

In GTK+ trunk, it is possible to override the global menu-images setting by connecting to the ::hide signal on the image and simply show it again. In some other bug (whose number eludes me right now), Jon proposed to add an explicit api to GtkImageMenuItem for this purpose.

The recent fixing of bug 322934 led me to think of a simple way of getting application developers to use icons more sparingly: Left-align the icons of menu items with have icons, with the text of items that don't have icons.

This would mean that if all the items in a menu section had an icon (which would usually be achieved by those items being objects like applications, file, device, or users), it would look fine:

    Go
    ==
      Back
      Forward
      Home
    ----------------------
      History      Ctrl H
    ----------------------
      [] Page A
      [] Page B
      [] Page C
      [] Page D
      [] Page E
      [] Page F
    ----------------------
      Earlier Today      >
      Yesterday          >

But if an application developer did the traditional thing of giving icons to most but not all items, it would look bad:

    File
    ====
      [] New                  Ctrl N
      [] Open…                Ctrl O
      Open Location…          Ctrl L
    ---------------------------------
      [] Save                 Ctrl S
      [] Save As…       Shift Ctrl S
      [] Revert
    ---------------------------------
      Page Setup…
      [] Print Preview  Shift Ctrl P
      [] Print…               Ctrl P
    ---------------------------------
      [] Close                Ctrl W

And the easiest way for the developer to fix the alignment problem of the items without icons would be to remove the icons from the other items, which is just what we'd want them to do.

This would work best, though, if the GTK+ change was synchronized with a clear interface guideline and perhaps a GnomeGoal to weed out unhelpful icons.

While an interesting idea, I don't think we are going to make changes to GTK+ that make UIs look bad for educational purposes...

Oh, it wouldn't be just for educational purposes. :-) That would merely be a pleasant side-effect. A more direct benefit of adopting that alignment would be that menu item icons, when present, would no longer use the same space normally used by menu item checkmarks. That in turn would mean that where a menu item had both a checkmark and an icon, the menu layout would be consistent with other menus that have only checkmark items or only icon items. (One example of a menu with both would be a user-account-switching menu, like the Fusa applet, with avatar icons and checkmarks for currently-logged-in accounts. Another example would be a partitioning tool, with a menu of checkmark items with icons for selecting which devices should be shown.)

gtk does not support menuitems that have both checks and icons

OpenSUSE is looking into disabling menu icons for the 11.2 release [1], adding Vincent to cc.

1. http://lists.opensuse.org/opensuse-gnome/2009-05/msg00044.html

What about waiting for 3.0 for such a change ?  As restated by Matthew in comment #14, "merely setting menus_have_icons=false by default, and doing nothing else, would not make anyone happy".  Especially as they don't expect such a change in 2.28, which would be one of the last 2. releases.

Obviously, in the meantime bugs could already be filed against applications to drop useless icons from their menus.

(In reply to comment #22)
> Obviously, in the meantime bugs could already be filed against applications to
> drop useless icons from their menus.

Let me just say... he have tried, we have failed ;)

I don't think the icon monster can be stopped without strict guidelines that are being enforced by the release team. Either that, or taking the icons-on-menus functionality out of GTK (which will not happen).

(In reply to comment #1)
> The Gnome interface guidelines don't mention when items should have icons, with
> one exception:
> <http://library.gnome.org/devel/hig-book/stable/menus-standard.html.en#menu-standard-bookmarks>

Do we have a bug open against the HIG for improving this?  If not could someone please file one.  I have some intention of getting back up to speed on my HIG work before and likely at GUADEC.

Overall I think this is the right move.  The menu items lack a real ability to style them in a way to draw attention to some common or useful menu items and detract from less common or useful items.  Because menu items are limited to text and icons we should strive to use icons sparingly to draw attention to important items and not use icons to decorate every item.  Once icons exist on every item their value in grabbing attention is lost.

I'm not sure what the best method forward is.  Turning off all icons isn't the end we want to achieve but reviewing each application and asking them to tone down icons is a long and very slow process.

(In reply to comment #23)
> (In reply to comment #22)
> > Obviously, in the meantime bugs could already be filed against applications to
> > drop useless icons from their menus.
> 
> Let me just say... he have tried, we have failed ;)
> 
> I don't think the icon monster can be stopped without strict guidelines that
> are being enforced by the release team. Either that, or taking the
> icons-on-menus functionality out of GTK (which will not happen).

I understand approaching applications without guidelines written down wouldn't get any result; but in my experience developers are quite happy to update their applications to the HIG.

(In reply to comment #24)
> I'm not sure what the best method forward is.  Turning off all icons isn't the
> end we want to achieve but reviewing each application and asking them to tone
> down icons is a long and very slow process.

I think the only realistic way forward is to turn off the ability to show icons in every menu item by changing menus_have_icons to be false by default.  Then we can selectively add back icons to those items that should have them by using the always-show-icons property of GtkImageMenuItem.

After further discussion with the gnome art community and the release team (at
GUADEC and on IRC) I've committed the change.  We will follow up with an email
on desktop-devel-list to give some guidance to application authors.

Anyone who does not like the new default may change the gconf setting to their
own preference.

Are you planning to remove all menu icons without distinction ?

It was quite logical to find icons in contextual menu for entries that also are in toolbar (and therefore already have their icons).

I.e for Epiphany which displays Back, Forward, Stop & Reload both in toolbar and in contextual menu, user is used to associate these icons with these actions.
It could be disturbing and seem illogical to not reproduce these icons in contextual menu. It would not be very consistant i think

this breaks bookmark favicons in firefox :/

Feel free to file a bug against Firefox.  I filed one for epiphany earlier today:
#588563

Firefox bug filed as https://bugzilla.mozilla.org/show_bug.cgi?id=504275

Has anyone checked other "not real gtk" apps? What about Qt apps for example (which is supposed to have this nice GTK look emulation)?

I added a request for guidelines in the HIG, bug 588668.

Michael Monreal : on Ubuntu 9.04, VLC 1.0.1-pre doesn't follow the set menus_have_icons=false setting

i've filled a bug against qgtkstyle about that : http://code.google.com/p/qgtkstyle/issues/detail?id=86

Why should there be an icon for documents and not for actions. I think it should be exactly the other way around (like its now). The icons help you to locate the actions. For docuements it would not help at all in 90% of the apps as all icons would be the same (the docuemnt icon the app can deal with).

I agree that we should have better guideline about their use.
E.g. refarding the repetitive use of the same icon for "Find", "Find next", we could recommend to only have it for "Find" and have "Find next" as the item following next, but without icon.

I agree with Stefan, above. I would just like to add that icons help people make associations between actions on menus and on toolbars. 

For example: 
1) open nautilus
2) notice the "reload" icon
3) open the "view" menu
4) notice the same "reload" icon
5) make an association: the two widgets activate the same "reload" action.

Without icons, the menus need *more weight*. Currently there is no way to set a font for gtk menus without setting for all interface elements. Is this not needed? I think my menus look really weak without icons, but with a bit more weight in the type, "naked" menus are better. But we need a separate option.

How do you set always-show-image when using GtkUIManager and a dynamically created GtkAction? We would need to do that for totem.

You get access to the menuitem via gtk_ui_manager_get_widget()

See http://git.gnome.org/cgit/eog/commit/?id=76ebcbeac7 for an example in eog.

That works, but I don't think one should have to fiddle with the proxies to do this; it should have GtkAction API. Filed as bug 589842.

Created attachment 139664 [details]
iconless dialog buttons screenshot

I guess that now that we have padding, I can somehow bear with the idea of iconless menus.

However, in Ubuntu's current development release, I noticed that dialog buttons (except toolbar buttons) do not have icons anymore. Is this an intentional result of this bug? Because if it is, I have to say we have fallen very, very low in the usability pit.

If it isn't, should I open a new bug report?

> should I open a new bug report?

No, you shouldn't. We have a separate gconf key for icons in buttons, and we've changed that default too. If you want them back:

gconftool-2 --type bool --set /desktop/gnome/interface/buttons_have_icons true

I disagree with the OP, for the reasons many others have stated.

If the problem here is that some apps use too many icons and clutter their menus, why not specify in the HIG that icons must be used only to highlight the most important items, and therefore shouldn't be used in more than 25% of the menu items?

Then we can file bugs against apps like evolution that overuse icons.

I also disagree with the OP, because I think his arguments are worthless.

- Many (if not most) of the GNOME designers agree with this
And the GNOME users? Do they agree with this?

- OS X and Vista don't show them (except for special cases)
Why has Linux always to be like OS X or Vista?

- Opening menus is much faster without them
If it would reduce the time for opening a menu from 5 seconds to 1 second, I would agree. But reducing opening time of menus from 5 hundreds of a second to one hundred of a second is silly. No one will notice that difference. You won't be able to open double the menus, even if time is five times shorter, let alone you can click that fast.

- The metaphors for the icons are often pretty useless
Don't know what to say about this one.

- It is much more elegant and less visually cluttered without them.
The command line is much faster, much more elegant and less visually cluttered.

That's one weak argument left (about the metaphors), which can't convince me this is a right decision.

/desktop/gnome/interface/buttons_have_icons false gives the buttons a bad aspect ratio. I very much prefer them to be higher. At false they look really bland.

(In reply to comment #45)
> /desktop/gnome/interface/buttons_have_icons false gives the buttons a bad
> aspect ratio. I very much prefer them to be higher. At false they look really
> bland.
> 

Whenever buttons have icons or not by default are outside the scope of this bug, please leave any comments about that in #583352 instead.

(In reply to comment #44)
> I also disagree with the OP, because I think his arguments are worthless.

Me and many others are tired of people that always come up to complain afterwards. Join discussions before decisions are made, or use a distro that sets the gconf key to true.
This is not the end of the world but just a configuration setting.

> - Many (if not most) of the GNOME designers agree with this
> And the GNOME users? Do they agree with this?

Feel free to ask "them", e.g. run a poll somewhere where probably 0.01% of "the GNOME users" will comment.

Now that this has been "fixed" , what about gnome 3.0?
Is there going to be a gconf option to have icons displayed or simply no icons at all with no gconf option?

Do remember that systems *have* gotten faster , and are now better able to handle the context menu loading. And systems are only going to get even faster... 
Users with a powerful system wouldnt mind having *some* icons.

We need proper rules for having the icons , 
have the gnome devs atleast started formulating such rules? 
If so kindly provide links of such discussions.

(In reply to comment #48)

> We need proper rules for having the icons , 
> have the gnome devs atleast started formulating such rules? 
> If so kindly provide links of such discussions.

Yes, see comment #1 by Matthew Paul Thomas.

Sorry guys, I didn't meant to be rude.
Conn made a good point however on the https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/407621. He stated that he didn't participate in a debate he wasn't aware that existed, that's probably the raison why the change was made. There's nothing wrong with that, people can't be everywhere. To me, if the icons are changed or not is less important, I only wish it was made more clearly to the user the icons were going to be changed, so the user could react appropriate and didn't have to complain afterwards. My reaction, for which I apologise, came just after I had seen the icons disappear. I didn't knew they were going to be changed. Very few users knew, as there have been two bug reports on launchpad in 1 day about this. I think that's the real problem, not if the icons are changed or not.

(in reply to comment #47)
As Conn didn't participate in a debate he wasn't aware that existed, I didn't follow the discussion because I wasn't aware of its existence. And sorry, but I don't think it's my task to run a poll about this matter.

(In reply to comment #50)
> I only wish it was made more clearly to the user the icons were going to be
> changed, so the user could react appropriate and didn't have to complain
> afterwards. My reaction, for which I apologise, came just after I had seen the
> icons disappear. I didn't knew they were going to be changed. Very few users
> knew, as there have been two bug reports on launchpad in 1 day about this. I
> think that's the real problem, not if the icons are changed or not.

I mentioned the change in my blog [1] and there was also a thread on desktop-devel [2] about it (although someone like jon, mpt or myself should probably have sent a mail announcing the change first, will do better next time).
I also expect it to be mentioned in the GNOME 2.28 release notes, the distros unstable release notes as well as their stable ones (as far as I can tell the change have not hit any beta or stable releases yet, so it only affects systems running the bleeding edge so far).
Matthias sent a e-mail about the change to fedora-desktop [3] and it would probably be a good idea for the other distro packagers to send out similar e-mails to their development lists in order to get the word out and avoid some bug reports about the behavior.

1. http://www.andreasn.se/blog/?p=103 (syndicated on Planet GNOME)
2. http://mail.gnome.org/archives/desktop-devel-list/2009-July/msg00126.html
3. https://www.redhat.com/archives/fedora-desktop-list/2009-July/msg00065.html

Opened some bugs on forcing the usage of icons in the case of applications, bookmarks places and files:
totem: 590660
gedit: 590661
Tomboy: 590653
nautilus: 590652

I strongly disagree with this decision. Additional icons increase usability and speed up finding the right entry in a menu a lot!

If you want to speed up gnome, take a look at XFCE, they really do a decent job in using aesthetically pleasant gtk2 stuff without making a loss in usability or speed.

I have no problem with icon-less menus or buttons by default but there indeed should be the possibility to configure gnome to include them. Getting rid of the ability to adapt gnome to the users needs has happened a lot over the last years, while trying to make gnome easier by reducing functions. This is a great disease and a step in the wrong direction. Making things easier is fine and cool for beginners and new users, but there ALWAYS should be the possibility to configure everything for the advanced user.

By the way, a good example for additional icons is the CuteMenus SVG extension for the Firefox web browser, which aims at supplying an icon to ANY entry in ANY menu. It doesn't slow down firefox in any way and it greatly enhances usability. Please think about it and don't take the usability out of one of the greatest desktop environments on the planet.

(In reply to comment #53)

> I have no problem with icon-less menus or buttons by default but there indeed
> should be the possibility to configure gnome to include them.

If the System > Preferences > Appearance > Interface tab should be kept or not
is outside the scope of this bug report and is being discussed here:
http://mail.gnome.org/archives/gnomecc-list/2009-July/msg00015.html

No icons have been removed, a gconf key have been altered and you can set to
true again if you wish.

We now have some nice and clean menus and buttons but there's one thing that really stands out now: icons on tabs! NetworkManager does this and I have seen other 3rd party apps doing it. I don't think a separate setting is needed for this, but can this be included in the hopefully-soon-to-be-published guidelines? E.g. only allow "favicons" on tab, not random category icons.

(In reply to comment #34)
> i've filled a bug against qgtkstyle about that :
> http://code.google.com/p/qgtkstyle/issues/detail?id=86

I have added support for "buttons_have_icons" and "menus_have_icons" to
the upcoming Qt 4.6.

André (comment #47) and Andreas (comment #51):

So sorry, but you're being ridiculous.

Are you asking me to make a list of every piece of software I use, find the blog of every developer, subscribe to every development mailing list, follow them, read all their release notes, etc?  My system currently has 1892 packages installed (yours probably has twice that)--what's your guess as to how long it would take me to track every proposed change and debate its merits?  Or are you saying that the only development team that I have to keep an eye on is that of Gnome?  That may be so, but I'm surprised that _you_ think so.

By and large I trust the developers to make good decisions.  Some decisions have better and worse answers, and many questions like this one have been studied extensively by corporations like MS and Apple.  A good developer will probably at least be aware of those studies.

When you decide to implement something, I will miss it.  When you make a questionable decision, I can only wait and see what the unexpected side-effects are.  When you make software that I use more difficult to use, THEN I will see, and then I will file a bug.  When you make it easier, I'll see it and probably not even thank you.  Asking your users to look over your shoulder and contribute their opinions before you make any decision is wonderful and shows that you care, but it's unrealistic.  I'm sorry, but you will only get feedback on things you do, not on things you say.  That's life.

The tough love of software development, eh?  I'm guessing it hurts more in open-source, for which I have little experience.  You'll have to take it on faith that your work is appreciated, despite all our whining :)

I was really disappointed when I found my new Ubuntu box (10.04) without the icons in context menus. I previously used the 9.04 version, which had those icons.
Actually I wasted more than one hour to find a way to restore them, since the Interface tab is missing from the Appearance configuration tool.
As a user I do prefer to have icons in context menus. This doesn't mean to have icons on all items, but some actions, like "Compress" or "Open in Terminal" should have the icon to facilitate the recognizability.

It's surely possible to provide a different default, but a tweak interface to modify gconf keys must be provided. Otherwise a previous user feels confused and is not able to restore the previous interface.
I can't understand why the tweak tab is disappeared.
Does it mean that you are going to remove also the gconf keys in the future?

More specifically, are you going to leave the users the ability to tweak the interface according to every own taste (at least using gconf-editor) or are you going to force every user to use always the same configuration (which could be good for one part of the user base, but bad for someone else)?
I hope that sentences like the following are not true...
"Although one article I have seen says that icons can be restored, I have seen discussion with Gnome developers which state that the Interface tab and the gconf options to restore icons to buttons and menus will be removed, which essentially means its their way or the highway."

To everybody:
Decision was made a while ago.
We are not interested in personal stories.
Bugzilla is not a forum.
Go somewhere else and stop adding unhelpful comments.
Otherwise your Bugzilla account might get disabled.

(In reply to comment #60)
First of all thank you for the wonderful welcome into Gnome community.

> Decision was made a while ago.

I've just discovered right now.
Is it a crime?

> We are not interested in personal stories.

That was not a personal story.
The point is: are you interested in collaborative opinions and help?
Even if they are posted after a while?

> Bugzilla is not a forum.

Is it a place to discuss about Gnome?
Is it open to everyone, even to me?

> Go somewhere else and stop adding unhelpful comments.
> Otherwise your Bugzilla account might get disabled.

Why are your threaten a new user who want to make Gnome better?

P.S.
Can you please reply to my question?
Are you going to remove also the gconf keys?

(In reply to comment #61)
> Is it a place to discuss about Gnome?

No. It's not a discussion place. It is a bugtracker.

> Why are your threaten a new user who want to make Gnome better?

I clearly wrote "To everybody:".

> Can you please reply to my question?

No, as it is the wrong place here.


Please do not respond to this comment.