GNOME Bugzilla – Bug 322932
Always show icons on panel menus
Last modified: 2020-11-06 20:21:40 UTC
If you set to false the GConf key /desktop/gnome/interface/menus_have_icons panel menus (not popups, but Menu Bar Applet and Main Menu applet) hide icons for menus entries. Is this the proper behavior? IMHO we should show icons here, hiding only in menubar's menus and popup menus.
Why should we show icons here?
Because the panel menu is not a "standard" menu and the panel menu bar in not a standard menubar. A standard menu (the one inside an application window) can provide only "actions" (select the menu entry and the application will do something related to application itself). If you hide proxy icons, you will be able to contextualize the menu entry. See for example my mockup on bug #322934 (id=55497). The panel menus provides a lot of diffente stuff (application launcher, bookmarked folders, mounted volumes and mounted remote volumes, preferences, quit and lock entries..). The latest week I tried to use GNOME hiding proxy icons: it was not so simple to me to find needed menu entry imeddiately. Of course this is just a personal feeling. I like to see more comments here, hopefully from usability people.
This is WONTFIX for me, but let's ask some usability people.
Hmm... I do agree with Luca that there's a conceptual difference between application menus and the main menu on the panel. Another difference is that every item on the panel menu does (or should) have an icon, which isn't true of application menus, which is one of the reasons people like to turn off application menu icons. Finally, the location of the preference in the UI (in the menus and toolbars capplet, with a preview picture of an application menubar) does kind of suggest that it will only apply to application menus. So, while I don't feel terribly strongly about it, I would at least admit that Luca might have a point :)
We should always show the icons in the applications menu at least. Conceptually I would say we should do the same for all the "main menu" menus. The icons here are primarily branding, rather than back/forward/etc... Branding is very important for people to find their applications. A neat usability test though, might be to "hide" all the icons in the windows start menu, and see if users can find programs they normally use. It would certainly help put the branding piece into perspective. The menus here are also always sorted alphabetically. This means that when you add or remove programs, the position of items in the menus changes. The places menu is also auto-populated when removable media is mounted. Perhaps we can disable the icons here if menus_have_icons is FALSE AND accessibility is enabled. This would be helpful for screen readers and braille output devices, I think.
Created attachment 125080 [details] [review] patch for the gtk+ part
Created attachment 125081 [details] [review] patch for the panel part
Ah, I just started to redo my gnome-panel patch for this last night... but it is only half-done yet, so you beat me.
Is the GTK+ patch in trunk? If not, I guess a GTK+ bug should be opened...
Not yet in trunk, I'll talk to Jon about it tomorrow.
Bug 322932 – Always show icons on panel menus * gtk/gtk.symbols: * gtk/gtkimagemenuitem.[hc]: Add a property to override the show-menu-images setting for individual menuitems. Patch by William Jon McCann.
Now that the GTK+ part is done any comments on the panel part? Thanks.
Instead of doing: item = gtk_image_menu_item_new (); + gtk_image_menu_item_set_always_show_image (GTK_IMAGE_MENU_ITEM (item), + TRUE); all the time, I'd prefer to create a panel_image_menu_item_new() that does this. Also, I guess we'll want to do this in libwnck/selector.c:wnck_selector_item_new() too?
Created attachment 131787 [details] [review] updated patch
Ping?
Some menu items were still showing no icon; I fixed this. Thanks!
Created attachment 139015 [details] [review] Fix showing icons on the wrong items We shouldn't be showing icons on categories, submenus, "actions".
I'd like to ask for the category icons to come back, it has been pointed in this bug report and in mailing list posts that the panel menu *is* different than the application menus, also this is kind of an important change (visually, not code-wise) to do for what will perhaps be the last gnome-panel release, GNOME 2 has had icons, and there is little point in pushing 3.0 design on the panel.
I disagree with William latest patch : categories / submenus and "actions" should have their icon. It is very disturbing for users to have a mix of non-icon and icons in the same menu and not showing icons at all is not better either.
I also disagree with removing the icons on the categories, actually I think this menu is very important and should be an exception from the guides and let all icons be shown. For example I would think a lot of children would recognize the (i) on/off icon. But please, at least revert the last patch.
(In reply to comment #17) > Created an attachment (id=139015) [details] > Fix showing icons on the wrong items > > We shouldn't be showing icons on categories, submenus, "actions". What is the exact reasoning for this? Why should "we" not show these icons ? If a change is being done at minimum a proper reason should have been stated. Removing icons from *the* main menu and not providing a reason for the change does not make it easy for us to understand and hence the choice is not of "we" the community but more of a personal preference.
The guideline I proposed, as quoted in bug 588668, is that "A menu item should have an icon only if it represents a dynamic object such as an application, file, device, or user". By "dynamic object" I mean the sort of item that can appear or disappear from the menu. An application category, such as "Programming", is a dynamic object: for example, uninstall every application that falls into the "Programming" category, and the item disappears. Therefore, I think the menu items for application categories (and subcategories, where used) should have icons. This way, panel menus would not be treated differently from any other menu. Jon disagreed on this, which is why he restored icons for applications but not categories. From #usability: <mccann> categories are labels <mccann> not sure it makes sense to come up with a metaphor for every label <mccann> and I don't think those metaphors help me identify the label
I've added back icons for categories in the applications menu, but not in the system menu, as discussed with mpt.
The remark in comment 20 about children recognizing the on/off icon is a good one. I think it even applies to a wider audience: many people who are not tech savvy have really grown used to icons like these. I think in this particular case removing the icon increases consistency for the sake of it, and totally ignores the underlying rationale for removing icons in the first place. Making the UI simpler by making it more consistent is a good thing and makes the desktop more usable in the general case, but some very well established metaphors like the on/off button cannot just be thrown overboard for this reason. Please, reconsider this particular case.
(In reply to comment #22) > The guideline I proposed, as quoted in bug 588668, is that "A menu item should > have an icon only if it represents a dynamic object such as an application, > file, device, or user". > mpt , its not a very convincing argument when you quote yourself ;) Not to discredit you , but , It would be more convincing if it was actually made *the* guideline... :) BTW , why isnt it a guideline yet and why are these icon changes being made on proposals made by a few? [i'm referring to this comment> https://bugzilla.gnome.org/show_bug.cgi?id=557469#c0 ] If all these changes were done systematically - making a guideline [which would have probably been brainstormed well enough] and - then changing the default behavior of the apps , we wouldnt have to be looking into such bugs or resentment from the community. This now seems like a haphazard move , and changes made only on realizing the bugs it causes!
(In reply to comment #24) > Please, reconsider this particular case. Wouter: did you see my comment (comment #23)? We put back some icons? Are you asking to put back more icons? (In reply to comment #25) > If all these changes were done systematically > - making a guideline [which would have probably been brainstormed well enough] > and > - then changing the default behavior of the apps , we wouldnt have to be > looking into such bugs or resentment from the community. > > This now seems like a haphazard move , and changes made only on realizing the > bugs it causes! You have to consider that the applications menu in gnome-panel is really a special case -- so it's not just about guidelines here.
(In reply to comment #26) > (In reply to comment #24) > > Please, reconsider this particular case. > > Wouter: did you see my comment (comment #23)? We put back some icons? Are you > asking to put back more icons? I'm a bit confused now. What I'd actually like to see are icons on both the log off and shutdown actions in the System menu, since people have grown SOOO used to those metaphors that removing the icon will certainly cause confusion (especially since both actions have icon-only applet equivalents showing exactly the same icon and having them in only one place would be really strange). I'm not sure whether these menu items in the System menu have an icon in the latest version. Do they? Bonne nuit! :)
(In reply to comment #27) > (In reply to comment #26) > > (In reply to comment #24) > > > Please, reconsider this particular case. > > > > Wouter: did you see my comment (comment #23)? We put back some icons? Are you > > asking to put back more icons? > > I'm a bit confused now. So was I :-) > What I'd actually like to see are icons on both the log off and shutdown > actions in the System menu, since people have grown SOOO used to those > metaphors that removing the icon will certainly cause confusion (especially > since both actions have icon-only applet equivalents showing exactly the same > icon and having them in only one place would be really strange). I'm not sure > whether these menu items in the System menu have an icon in the latest version. > Do they? Okay, much clearer now. Those icons are not back -- the System menu is without icons (except for the items in the preferences/administration submenus). So, my take is that I won't put them back unless someone from the usability team steps up and tells me to do so. I don't have a strong feeling either way... Can you please take this to the usability mailing list?
vuntz, You said that you don't care if the icons are there or not and also that the gnome-panel menu is special. Also you'd like us to bring this up on the usability mailing list. If we look at it from another perspective - has the usability team specifically asked you to remove the icons, except for the blogpost about the new "design guides"? Changing this in one of the last releases (?) of gnome-panel seems unnecessary - just let the good old gnome-panel stay as it always has and let gnome-shell guide us in to the future. Note that I've got no opinion about the icons in the normal menus, and not for the buttons either - but the gnome-panel, as you've said, is special and just make gnome look bad as it looks like right now.
I agree with Marcus in comment 29 that there is no need to take this to the usability team. Other than a rather vague guideline that doesn't apply directly to the panel but only to menus in general (we already agreed the panel is a special kind of menu, right?), there is no reason to make such a visible UI change. It does not sound wise to me at all to break thing when they are not broken.
Apologies for commenting on something that seems finalised but I have, for a long time, not had any icons in panel menus by preference and so see these changes as a little regression. When setting menus_have_icons to false I actually wanted the behaviour described in the original bug submission. From the lack of similar opinions expressed in forum debates about this issue and in downstream bug reports I can only think I am a niche case. However, I would like to add another point for leaving well alone for now. I was content and happy with the prior behaviour of icons on /or/ off. Now in Rawhide I do not have that option.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.