GNOME Bugzilla – Bug 171424
Empty menus behaviour
Last modified: 2013-11-10 18:21:22 UTC
From the API docs: <snip> GtkUIManager offers two ways to treat empty submenus: * make them disappear by hiding the menu item they're attached to * add an insensitive "Empty" item The insensitive "Empty" item isn't the best behaviour, for non-toplevel menu items, as it requires the user to go inside the submenu to discover that a function isn't available. It would be more straight-forward to make the parent of the submenu insensitive, while retaining its label. For example, from Totem (insensitive items in between []): Before: Movie Edit Sound Languages -> [No language selection available] After: Movie Edit Sound [Languages]
Created attachment 58955 [details] [review] gtk-demo-empty-menu.patch Patch to gtk-demo to test the changes.
The code to looks at would be update_smart_separators() in gtk/gtkuimanager.c and _gtk_action_sync_menu_visible() in gtk/gtkaction.c
Created attachment 58986 [details] [review] gtk-ui-manager-make-empty-menu-insensitive.patch This makes the menu itself insensitive. As the "Empty" menu item is not shown anymore, I removed the string for translation. Should we completely get rid of the submenu item, and replace it with a boolean instead?
Nope, can't easily get rid of the filler, as it does show up in the list of children.
I would like to see this being done as an additional property "insensitive-if-empty" instead of simply changing the meaning of "hide-if-empty"
I'm really not sure it's worth it. The change in behaviour is minimal, and would get rid of an unused submenu, improving discoverability (no need to go into the submenu to see there's no items). It's a usability change more than anything else.
I don't know if the change can be described as minimal. The description of GtkAction::hide-if-empty is pretty explicit about the behaviour: When TRUE, empty menu proxies for this action are hidden Suddenly not making them invisible, but insensitive will render the documentation incorrect.
But GtkAction::hide-if-empty is TRUE by default. What I'm changing is the behaviour when it's FALSE. The behaviour when hide-if-empty is TRUE doesn't change. Adapted from comment #1 (there's not even a way to set the label of the filler): For example, from Totem (insensitive items in between []): Before: Movie Edit Sound Languages -> [Empty] After: Movie Edit Sound [Languages]
I raised this on Usability mailing list to get things moving again: http://mail.gnome.org/archives/usability/2007-March/msg00033.html
Created attachment 84846 [details] [review] Refreshed patch for svn trunk Here's a remade patch against svn trunk, the previous one didn't apply cleanly (for some reason the untranslated string change wasn't accepted as-is).
I think that making the parent menuitem insensitive is making the menus less usable. You are taking the information that the submenu is empty away from the user - he just sees a disabled item and has no chance to open the submenu and check if it is empty of if some large sets of features are inaccessible to him because some configuration has disabled them.
(In reply to comment #11) > I think that making the parent menuitem insensitive is making the menus less > usable. You are taking the information that the submenu is empty away from the > user - he just sees a disabled item and has no chance to open the submenu and > check if it is empty of if some large sets of features are inaccessible to him > because some configuration has disabled them. It's true, there wouldn't be any difference between an empty sub-menus, and a disabled "parent" menu item. But the user wouldn't be able to see the submenu items in the case of disabled/unaccessible features. I'd argue that for disabled features, it should be the individual menu items in the submenu that should be disabled, otherwise, there's no way to know what is in the submenu (and thus, which features aren't available).
(In reply to comment #11) > I think that making the parent menuitem insensitive is making the menus less > usable. You are taking the information that the submenu is empty away from the > user - he just sees a disabled item and has no chance to open the submenu and > check if it is empty of if some large sets of features are inaccessible to him > because some configuration has disabled them. I guess it boils down to functionality vs. features. From feature POV, yes you want to show "no features here" (to differentiate from "these features here"). But from functionality POV, you gain nothing from showing "you cant do anything with this menu" vs disabling the menuitem and indicating it a click earlier. My vote is with the functionality POV. I wouldn't argue against a separate property though, if the change feels uncomfortable.
Patch 84846 applies cleanly. Reviewing it would take little time. (Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
What's the status of this three year old bug? If Matthias still isn't convinced that making the GtkMenuItem insensitive when hide-if-empty=FALSE, then shouldn't this bug be closed? Let's get some closure.
Whats the pressing need to close this bug (other than collecting bugzilla points :-) ? And yes, I'm still not convinced.
There is no pressing need, but if you aren't convinced, then I don't see how this bug is ever going to get resolved. If there *is* a way to convince you, then it would be good if you documented that procedure. :)
(In reply to comment #16) > Whats the pressing need to close this bug (other than collecting bugzilla > points :-) ? > > And yes, I'm still not convinced. Would it be acceptable to have a separate option that only takes effect with hide-if-empty=FALSE?
I think that is essentially what I proposed in comment #5
not going to happen at this point, I think