GNOME Bugzilla – Bug 337428
reorganize preferences, administration menus
Last modified: 2021-05-25 12:46:08 UTC
To a user, the differences between the configuration tools in the "Preferences" menu and the "Administration" menu are not always clear, and the menus are becoming quite long, slowing the process of finding the right tool to accomplish a given configuration. There are also useful configuration tools in the applications menu. (gconf and menu editor for example). These menu items could be combined into one "Configuration" menu (I'll leave it to others to decide where this would reside), organized into a number of categories. The categories should group related tools together, and possibly have some sort of visual indication of more advanced tools within a category. One possible organization: Language & Interaction - input devices, input methods, assistive tech, sound, language settings Network & Printing - (should be obvious) Display & Desktop - (should be obvious) Applications - preferred apps, app update & install, software properties, gconf Users & Sessions - sessions, users & groups, login window, about me Disks & Drives - (should be obvious) System Tools - Time & Date, system log, system mon, services, power Other information:
I agree there's an issue here; this was a bit of a dilemma for us when putting together the OpenSolaris JDS spec (out-of-date version at http://www.gnome.org/~calum/nevada/ui-spec/index.htm ; I'll try and upload the latest version soon.) As you'll see there, I made a stab at trying to define what the definition of "Preferences", "Administration" and "System Tools" might be: Preferences: Contains settings that affect the appearance or behaviour of the current user's desktop only. Administration: Access to settings that alter the behaviour of the machine (or something attached to it) on which the user's session is running. Changes affect all users who subsequently log into that machine. System Tools: Applications that give information about or access to the machine on which the user's session is running, but which don't generally affect that machine's behaviour. These certainly isn't perfect (it was partially written to rationalize what was already there), but it would be good to try and agree on a definition for each category and take it from there. The descriptions in the list of registered categories in the Desktop Menu Spec (http://standards.freedesktop.org/menu-spec/latest/apa.html) could possibly be more useful in this regard too. As you can see from the JDS spec, as a result of our attempt at the definitions we're deviating more than we'd like to from the community menus, and we'd like to think there's at least somewhere we can meet in the middle here.
Calum: is this something you could take on the xdg list?
I can give it a go... it's a topic that's come up again inside Sun in the past couple of weeks, actually, so maybe I'll see if I can persuade the people who are worrying about it this time to take it on from here :)
We can use the structure from gnomecc.menu, actually.
*** Bug 534000 has been marked as a duplicate of this bug. ***
Created attachment 137637 [details] [review] Reorganizes the pref/admin menus to match categories in gnomecc I have also pushed my branch to github git://github.com/kenvandine/gnome-menus.git
I'm looking in the same direction now, thinking about how to make the GNOME menu more usable on netbooks. What I've done is adding to /etc/xdg/menus/settings.menu the following simple line: <MergeFile>gnomecc.menu</MergeFile> and removing the Preferences menu from settings.menu altogether. This gives a great advantage of reusing the same hierarchy in two places. There are two downsides of this, however: 1) gnomecc.menu may not necessarily exist in the system (it is shipped with another module) 2) gnomecc.menu does not make "Other" menu, and this leads to spilling items to the top level menu. I'm now working on them. If anyone's interested, I'll attach the resulting settings.menu and gnomecc.menu here.
FWIW, this is what I suggested in comment #4. We should just kill gnomecc.menu and move its content to settings.menu (modulo a few changes).
(In reply to comment #8) > FWIW, this is what I suggested in comment #4. We should just kill gnomecc.menu > and move its content to settings.menu (modulo a few changes). That would be best.
Created attachment 139474 [details] Moving substantial menu parts from gnomecc.menu to settings.menu This is the settings.menu file I ended up with. The next attachment is the corresponding gnomecc.menu file
Created attachment 139476 [details] gnomecc.menu uses the menu from settings.menu, with slight changes gnomecc.menu takes almost everything from settings.menu, removing gnomecc.menu and Administration menu from it. The only difference from the current state is that ungrouped .desktop files now hit Other submenu, rather than Control Center menu.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/gnome-menus/-/issues/ Thank you for your understanding and your help.