Comments on: Squib of the day: all (or some) menu options should have icons http://blogs.gnome.org/metacity/2009/03/22/squib-of-the-day-all-or-some-menu-options-should-have-icons/ "Many window managers are like Marshmallow Froot Loops; Metacity is like Cheerios." Sun, 26 Sep 2010 15:08:40 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Calum http://blogs.gnome.org/metacity/2009/03/22/squib-of-the-day-all-or-some-menu-options-should-have-icons/comment-page-1/#comment-969 Calum Fri, 03 Apr 2009 14:37:27 +0000 http://blogs.gnome.org/metacity/?p=532#comment-969 (Unless, of course, you count the title bar as a 'toolbar'-- in which case, I guess, it makes sense to continue to show the icons for Minimize, Maximize, Unmaximize and Close on the menu, which was probably the original rationale for the current situation anyway....) (Unless, of course, you count the title bar as a ‘toolbar’– in which case, I guess, it makes sense to continue to show the icons for Minimize, Maximize, Unmaximize and Close on the menu, which was probably the original rationale for the current situation anyway….)

]]> By: Calum http://blogs.gnome.org/metacity/2009/03/22/squib-of-the-day-all-or-some-menu-options-should-have-icons/comment-page-1/#comment-968 Calum Fri, 03 Apr 2009 14:19:05 +0000 http://blogs.gnome.org/metacity/?p=532#comment-968 The initial idea of icons on menus, when Microsoft foisted it upon us, was so that you could easily identify menu items that had an equivalent on the application's toolbar. Since none of the window menu icons appear on any toolbar, I don't see any need for icons on the menu at all. The initial idea of icons on menus, when Microsoft foisted it upon us, was so that you could easily identify menu items that had an equivalent on the application’s toolbar.

Since none of the window menu icons appear on any toolbar, I don’t see any need for icons on the menu at all.

]]> By: Screwtape http://blogs.gnome.org/metacity/2009/03/22/squib-of-the-day-all-or-some-menu-options-should-have-icons/comment-page-1/#comment-935 Screwtape Sun, 22 Mar 2009 03:47:49 +0000 http://blogs.gnome.org/metacity/?p=532#comment-935 I have to say that the opinions in the bug all look pretty well-thought-out and reasonable. - If a menu item has an icon in one state, it should continue to have an icon when its state is toggled, such as the "Maximize" menu becoming "Unmaximize" on an already-maximized window (the writeup suggests that there may be two items appearing in the same menu that are inverses of each other; it turns out that's not actually the case). It might even have the same icon in both states. - Not every menu-item should have an icon, just the most important ones. - The current menu item icons correspond to Windows' standard button-glyphs, but the actual button glyphs of the window are drawn by the Metacity theme; it only seems fair for consistency that the menu icons are drawn by the theme too. Making menu-icons from existing themes would be difficult - you'd have to draw a full titlebar to a pixmap and crop out the button-shapes you needed. The alternative is to add special "window parts" used to draw the menu-icons, so the theme can create icons that resemble the buttons, but are designed to work in a menu context (for example, in a menu a theme can't control the background colour). - If a Metacity theme doesn't supply specific instructions for drawing menu icons, it seems quite a good idea to load menu icons from the icon theme - bundling an icon theme with a Metacity theme seems a pretty easy thing to do. - Another idea only lightly brushed on in the bug is that the existing icons don't work very well in many GTK+ themes - since they're plain black, they can be hard to see if you're using a dark theme, or if you're using a light theme with a dark highlight-colour. I have to say that the opinions in the bug all look pretty well-thought-out and reasonable.

- If a menu item has an icon in one state, it should continue to have an icon when its state is toggled, such as the “Maximize” menu becoming “Unmaximize” on an already-maximized window (the writeup suggests that there may be two items appearing in the same menu that are inverses of each other; it turns out that’s not actually the case). It might even have the same icon in both states.

- Not every menu-item should have an icon, just the most important ones.

- The current menu item icons correspond to Windows’ standard button-glyphs, but the actual button glyphs of the window are drawn by the Metacity theme; it only seems fair for consistency that the menu icons are drawn by the theme too. Making menu-icons from existing themes would be difficult – you’d have to draw a full titlebar to a pixmap and crop out the button-shapes you needed. The alternative is to add special “window parts” used to draw the menu-icons, so the theme can create icons that resemble the buttons, but are designed to work in a menu context (for example, in a menu a theme can’t control the background colour).

- If a Metacity theme doesn’t supply specific instructions for drawing menu icons, it seems quite a good idea to load menu icons from the icon theme – bundling an icon theme with a Metacity theme seems a pretty easy thing to do.

- Another idea only lightly brushed on in the bug is that the existing icons don’t work very well in many GTK+ themes – since they’re plain black, they can be hard to see if you’re using a dark theme, or if you’re using a light theme with a dark highlight-colour.

]]>