After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 71867 - Advise regarding toggable menu options
Advise regarding toggable menu options
Product: gnome-devel-docs
Classification: Applications
Component: hig
Other All
: Normal normal
: ---
Assigned To: HIG Maintainers
HIG Maintainers
Depends on: 101884
Reported: 2002-02-18 19:23 UTC by Christian Rose
Modified: 2020-12-04 18:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Christian Rose 2002-02-18 19:23:19 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.
Comment 1 Murray Cumming 2002-12-10 12:53:14 UTC
What is wrong with the default GTK+ radio and check menu items?
Comment 2 Christian Rose 2002-12-10 13:26:33 UTC
Are those possible to have in menus? Are the use of those in menus
specified in the HIG?
Comment 3 Murray Cumming 2002-12-10 13:32:02 UTC
Yes, they are:

Why should the HIG mention them? What is the problem?
Comment 4 Christian Rose 2002-12-10 13:52:17 UTC
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.
Comment 5 Murray Cumming 2002-12-10 14:01:36 UTC
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.
Comment 6 Christian Rose 2002-12-10 14:37:08 UTC
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.
Comment 7 Murray Cumming 2002-12-10 14:43:20 UTC
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.
Comment 8 Christian Rose 2002-12-10 15:13:17 UTC
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.
Comment 9 Murray Cumming 2002-12-24 00:33:33 UTC
Added bug #101884 asking GTK+ to solve this problem.
Comment 10 Murray Cumming 2003-05-31 15:16:51 UTC
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.