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:
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
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
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