GNOME Bugzilla – Bug 71867
Advise regarding toggable menu options
Last modified: 2020-12-04 18:19:00 UTC
There should probably be clear advise regarding toggable menu options. Whether they should be differently labeled than regular menu options, whether they should have checkboxes, whether the unchecked state should be clearly different from other types of menu options, etc.
What is wrong with the default GTK+ radio and check menu items?
Are those possible to have in menus? Are the use of those in menus specified in the HIG?
Yes, they are: http://www.gtk.org/tutorial/sec-menuitems.html http://developer.gnome.org/doc/API/2.0/gtk/GtkCheckMenuItem.html Why should the HIG mention them? What is the problem?
Well, perhaps because it has been proved unclear to developers in the past how to best represent a toggable preference in a menu. This bug report was a result of such a big thread on the galeon-devel list, if I remember correctly. So the issue is which one of these approaches is better from a usability perspective and should be used within GNOME (a HIG recommendation): Different labels: "Enable foo" / "Disable foo" Checkboxes: "X Foo" / " Foo" In the latter case, it would be useful to have a recommendation of what the unchecked state should look like ("[ ] Foo" vs just " Foo"), since the latter perhaps doesn't give enough visual hint that this is a toggable setting and thus different from other menu options. Really, this issue is orthogonal to whether any approach is already possible or not -- the issue is about having a recommendation on which approach to use clearly stated in the HIG.
I suspect that GNOME people think that radio menu items and check menu items should be used, and that that's why GTK+ makes them available. Do you know of any applications that use 2 mutually-exclusived menu items instead? I think we need a real-world example in order to have any discussion of this.
There are many things that are available in GTK+ but don't match HIG recommendations. GTK+ has backwards compatibility to live with, the HIG has not. I think it's a dangerous assumption to make that we don't need HIG recommendations because whether the toolkit supports it should give enough hint. The HIG exists partly to allow for the toolkit to get changed where needed, and thus some things in the HIG are bound not to be implemented in the toolkit or implemented in a different way in the toolkit at any given time. Thus, it's not clear to me whether you suggest that we don't have any HIG at all. Regarding examples, one that I found just by playing around with GNOME menus is the one in gnome-terminal. It has "Show menu bar" and "Hide menu bar" in its View menu, whereas many other GNOME applications use a checkbox for things like this. Gnibbles just has "Pause", regardless if the game is paused or not, etc.
I'm not suggesting that we don't need a HIG. I'm saying that you don't need to question everything before you've even looked at the defaults. I'll ask on the list about whether mutually-exclusive menu items should be considered a bad thing.
Again, this bug report was issued as a result of a specific discussion about a specific issue in the HIG that proved to be unclear to developers - so I'm not trying to open bug reports at random and question everything, just where things have proven to be unclear if they are advisable or not, even to developers that are familiar with toolkit defaults. I'm glad that you will be bringing this issue up again.
Added bug #101884 asking GTK+ to solve this problem.
People might want to submit bugs against themes that do not show the state properly. See bug 101884 for a screenshot of a theme (mist) that seems to do this properly. Otherwise, unless this bug gets a bit more focused, I'll probably close it.