GNOME Bugzilla – Bug 93506
Cannot add menu items to menus which don't contain launchers
Last modified: 2020-11-06 20:26:01 UTC
Right clicking on a submenu in the Applications menu or Gnome menu has no effect. Right clicking on a menu item (other than a submenu) in the Applications menu or GNOME menu provides a pop-up menu with the following items: Add this launcher to panel Remove this item Put into Run dialog Properties Entire Menu --> Add this as Drawer to panel Add this as menu to panel Add new item to this menu Properties This means that : - you can't add a launcher to an empty menu (since you can't enter menu) - if a menu only contains submenus, you cannot add a launcher to the menu. - you can only add a menu as a drawer or a menu to a panel if the menu contains at least one launcher This would be solved, by allowing right-clicking on the menu name which gives the popup: Add this as Drawer to panel Add this as menu to panel Add new item to this menu Properties and by removing the item 'entire menu' from the popup for menu items other than submenus. It also clarifies to which menu/item the two 'properties' pertain The only downside of this might be that you now cannot add a launcher to the top-level Applications Menu - unless you allow right-clicking on the Applications button itself. The user would be able to do this anyway through the Gnome menu since Applications is submenu of Gnome menu.
Another proposal which gets rid of the horrid "Entire Menu" monstrosity altogether (HIG doesn't approve of submenus on popup menus) and lets you add stuff to the Applications menu in the same way as any other might be: For launcher L on menu M: Run --- Properties Remove --- Help on <L> ** --- Add New Item to <M>... --- Add <L> to panel Add <M> as drawer to panel* Add <M> as menu to panel For submenu <S> on menu <M>: Properties Remove --- Add New item to <S>... *** Add New item to <M>... --- Add <S> as menu to panel Add <S> as drawer to panel* --- Add <M> as menu to panel Add <M> as drawer to panel* Might also be nice to have an "Edit.." item on both menus that just plonked you into the appropriate menu-editing Nautilus view. * Do we really need to keep the 'add as drawers' items? Does anyone use them? Would make these menus look much nicer if we could get rid of them :) ** I'd be tempted to get rid of this one too, who needs help on an application they haven't run yet? *** Perhaps, although maybe it wouldn't be a bad idea to make people open the submenu they want to add things to before we let them add things to it.
> Add New item to <S>... *** > >*** Perhaps, although maybe it wouldn't be a bad idea to make people > open the submenu they want to add things to before we > let them add things to it. Have to be able to add to an empty menu ! Other issues for consideration: - If a menu is added to the panel, there has to be a way to change its icon. The current 'entire menu' approach allows for this for non-empty menus (though it doesn't currently work and it's non-intuitive to have to drop 3 levels of menus to change the icon at the top). Putting back a 'properties' in right-click of a panel menu icon would address this. - If a menu is added to the panel, there has to be a way to add new icons to it. Again the 'entire menu' approach allows for this for non-empty menus. - I don't believe you should be allowed to remove submenus if you can't add submenus. Better to leave this for within Nautilus ?
In response to part of my previous comment: Who needs panel menus ? I can't create a menu on the panel. The only way to do this is copy an existing menu/submenu to the panel as a menu and then edit its icon and contents. But editing a panel menu applies the same changes to the menu from which it is derived (actually it's worse than that - right clicking on the panel menu icon and changing the icon, changes the icon of the submenu from which it was derived, but not the icon of the panel menu !) Allowing a user to copy menus to the panel misleads a user. Only after editing it, will they discover they modified the source menu. Since drawers can be created from scratch, or created from submenus, and can be tailored without affecting the menu/drawer from which they may have originated, what is the value of any menu other than the Applications Menu (and the Gnome Menu) ?
> Have to be able to add to an empty menu ! Hmm, I guess so, although the fact that empty menus appear at all (at least system-created ones) is pretty unpleasant and oft-complained about. > I don't believe you should be allowed to remove submenus if you > can't add submenus. Better to leave this for within Nautilus ? True, that's a bit of an oversight (in my proposal, at least)... I don't see why you shouldn't be able to add submenus the same way as you can add launchers, if you want to. You're right about being able to create menus too... this is kind of pointless/dangerous the way things work right now, it would probably be better to remove those options.
Mark? Any word on this one?
*** Bug 73741 has been marked as a duplicate of this bug. ***
> Might also be nice to have an "Edit.." item on both menus that just > plonked you into the appropriate menu-editing Nautilus view. Definately! however, I think that "Browse..." might be more accurate as it would be opened in nautilus and not a specific menu editing app. Once we have a Browse or Edit item and have bug #92719 fixed we could nuke start-here :)
*** Bug 99110 has been marked as a duplicate of this bug. ***
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
All gone a bit quiet on this one... ping?
I tried to work on this, but I had this problem: once a submenu is open, the click event (or whatever it is, maybe button-press) doesn't work for the submenu item. Is it a known problem with GTK+ or was my code simply badly written? I could see the context menu for the submenu item work if I right-clicked quick enough, before the submenu opens.
*** Bug 97970 has been marked as a duplicate of this bug. ***
*** Bug 139870 has been marked as a duplicate of this bug. ***
Seems like this has died once again. Vincent, perhaps attaching your patches to this bug will at least give a collection of what you have done. Maybe someone else will pick it up if you haven't already finished it, which you probably have ;-)
Hum... I think I lost the patches when I did some 'rm -rf' magic :-( But IIRC, there is a patch in another bug implementing that. Will need to look for that when I'll have more time.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
This is a dupe of 82241 and the other "gnome menuing system sucks" bugs only 82241 is properly listed as enhancement. All these dupe'd menu editing bugs should be collected and considered as a GUI issue for 2.12.
just wondering is there any activity on this ?
Well, the original bug is fixed since we don't add menu items this way anymore. However, the other comments are about the right-click menus. Some work should be done here, but basically, GTK+ doesn't help us here (popup menus on menu items are not really usual).
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.