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 645061 - Tools to perform system administration should be available in the menus somehow
Tools to perform system administration should be available in the menus somehow
Status: RESOLVED OBSOLETE
Product: gnome-menus
Classification: Core
Component: layout
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-menus dummy account
gnome-menus dummy account
Depends on:
Blocks: 645063
 
 
Reported: 2011-03-17 19:14 UTC by William Jon McCann
Modified: 2021-05-25 12:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Experimental addition of Administration tools to the App menus (991 bytes, patch)
2011-03-17 19:15 UTC, William Jon McCann
reviewed Details | Review
layout: Show administration tools and old capplets in Other (1.22 KB, patch)
2011-03-30 07:26 UTC, Vincent Untz
committed Details | Review
layout: add System Administration menu (1.68 KB, patch)
2011-04-29 20:22 UTC, Ray Strode [halfline]
none Details | Review

Description William Jon McCann 2011-03-17 19:14:53 UTC
Downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=685142

Things like the old-school techy firewall configuration tools need a place in the menus if they exist on the system.  They used to be available under the System->Administration menu but that isn't applicable to GNOME 3 default or fallback mode.
Comment 1 William Jon McCann 2011-03-17 19:15:43 UTC
Created attachment 183669 [details] [review]
Experimental addition of Administration tools to the App menus
Comment 2 Vincent Untz 2011-03-17 19:43:07 UTC
Just to clarify a few things:
 - the tools don't fit in the system settings because of the design, right? (ie, system settings are for user stuff; I must admit that I find it confusing we have user accounts there, though)
 - are we fine having Administration appear first in the categories? Or do we want to define an order?
 - what's the long term design for system-wide configuration tools? Are we going to migrate them somehow to another control center shell? To merge them with current system settings? To keep them in the menus?
Comment 3 Colin Walters 2011-03-17 19:45:43 UTC
See also gnome-shell bug https://bugzilla.gnome.org/show_bug.cgi?id=645063
Comment 4 Colin Walters 2011-03-17 19:47:34 UTC
(In reply to comment #2)
> Just to clarify a few things:
>  - the tools don't fit in the system settings because of the design, right?
> (ie, system settings are for user stuff; I must admit that I find it confusing
> we have user accounts there, though)

I think it's more that the tools have no design or coherency with the system settings; we don't have a good story for them.

>  - are we fine having Administration appear first in the categories? Or do we
> want to define an order?

One thing Jon pointed out is it's pretty lame that we alphabetize; actually even worse things change place depending on translation, right?

>  - what's the long term design for system-wide configuration tools? Are we
> going to migrate them somehow to another control center shell? To merge them
> with current system settings? To keep them in the menus?

I think the long term design is to both evolve the GNOME system settings, but also as much as possible make the legacy vendor tools unnecessary.
Comment 5 Vincent Untz 2011-03-17 20:00:01 UTC
(In reply to comment #4)
> (In reply to comment #2)
> >  - are we fine having Administration appear first in the categories? Or do we
> > want to define an order?
> 
> One thing Jon pointed out is it's pretty lame that we alphabetize; actually
> even worse things change place depending on translation, right?

We don't have to alphabetize; it's just the default. That being said, it's generally a good thing because it makes it faster to read for people (in general). But if we want to force an order, we can.
Comment 6 William Jon McCann 2011-03-17 20:18:21 UTC
(In reply to comment #2)
> Just to clarify a few things:
>  - the tools don't fit in the system settings because of the design, right?
> (ie, system settings are for user stuff; I must admit that I find it confusing
> we have user accounts there, though)

Basically everything in Administration should go away eventually.  Unless you are using some kind of server or something.  Some of these can already go.  User accounts should definitely be removed right away I think.

>  - are we fine having Administration appear first in the categories? Or do we
> want to define an order?

No, not really fine with it.  I think having an order would be useful.  Either that or we can maybe invent a new name starting with Z or something :)  We also have these System Tools things that are sorta similar but different enough to warrant a separate section - but at the same time it is a little confusing.

Another obvious candidate for ordering is Other.  It should certainly be last in the list I think.

>  - what's the long term design for system-wide configuration tools? Are we
> going to migrate them somehow to another control center shell? To merge them
> with current system settings? To keep them in the menus?

If they are things that ordinary users need to do they ought to be merged into System Settings.  Mostly we're already there or will be by 3.2.  User accounts, date/time, printing can probably go right now.  Firewall - we still have to figure out the GNOME story there.  Language should be able to go once we finish the Region & Language panel (3.2).  LVM etc should go into Disk Utilities (palimpsest).
Comment 7 Matthias Clasen 2011-03-18 12:05:31 UTC
Putting this on 3.0 target to keep it on the radar.
Comment 8 Vincent Untz 2011-03-18 15:33:55 UTC
Comment on attachment 183669 [details] [review]
Experimental addition of Administration tools to the App menus

So once someone defines the order we want for the menu, we can commit :-)

Or we can just commit this for now (since the patch is fine) and define the order later.
Comment 9 Matthias Clasen 2011-03-21 00:10:11 UTC
I think the question of order (and locale-dependence) is orthogonal to adding the admin tools. So +1 to committing the current patch as-is.
Comment 10 Vincent Untz 2011-03-22 18:25:27 UTC
Gah. We need string freeze break approval to add a Settings-System.directory.in file. Can you request this please?
Comment 11 Vincent Untz 2011-03-30 07:26:52 UTC
Created attachment 184663 [details] [review]
layout: Show administration tools and old capplets in Other

Alternative patch, to show the .desktop files in Other. This is not perfect, but it doesn't add any string.
Comment 12 Colin Walters 2011-03-30 16:28:09 UTC
Review of attachment 184663 [details] [review]:

That sounds OK; I'm a bit worried about suddenly pulling in other stuff we don't want, but I guess if crap is installed, it's not our fault.

In Fedora e.g. I see ibus-setup.desktop which would now be in the list (but this is ok because it's NoDisplay=true).
gpk-prefs.desktop would now be shown though.
So would desktop-effects.desktop (eww =/ )
And gst-mixer.desktop.

But, oh well.  Again this is a vendor problem I think.
Comment 13 Vincent Untz 2011-03-31 07:14:28 UTC
Comment on attachment 184663 [details] [review]
layout: Show administration tools and old capplets in Other

Committed this, but leaving the bug open as we want a better fix later on.
Comment 14 Vincent Untz 2011-03-31 07:15:07 UTC
Now that we at least don't lose those .desktop files, this is not a blocker anymore. But we'll want a better fix for 3.2, so moving to 3.2.
Comment 15 Ray Strode [halfline] 2011-04-29 20:22:19 UTC
It really feels like these tools should be in their own category.
Comment 16 Ray Strode [halfline] 2011-04-29 20:22:44 UTC
Created attachment 186904 [details] [review]
layout: add System Administration menu

This is a place to nicer than Other for
not-installed-by-default system administration
applications to sit.
Comment 17 Adam Williamson 2011-05-10 17:34:44 UTC
As discussed in downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=697834 , the use of the two top-level categories System and Settings together to mean 'core administration tools' is an abuse of the fd.o menu layout spec (http://standards.freedesktop.org/menu-spec/latest/ ) and a Fedora-ism at that; no other distro uses that system AFAIK.

Per the upstream spec, .desktop files should specify only one top-level category, and use sub-categories to define themselves more specifically.

The big thing that's missing here, simply in terms of spec compliance, is that gnome-menus does not account for the category Settings at all; it's a standard top-level category per the fd.o spec, so gnome-menus really ought to account for it.

I don't think upstream gnome-menus should adopt the Fedora-ism of System+Settings, it should just handle the Settings category (probably with a new menu called Settings or Preferences or something), and Fedora .desktop files should be adjusted to match the upstream spec and hence be properly categorized in GNOME...
Comment 18 Adam Williamson 2011-05-10 17:40:51 UTC
"Per the upstream spec, .desktop files should specify only one top-level
category"

well, it doesn't really require this, but it's clearly the intent, and it warns that specifying more than one top-level category can lead to menu duplication.
Comment 19 Matthias Clasen 2011-09-16 16:48:43 UTC
Vincent, were you going to make any changes for this ?
Comment 20 Vincent Untz 2011-09-19 13:20:50 UTC
This really shouldn't be a blocker anymore. Here's the latest status I sent on d-d-l at the beginning of September:

=====
(Note that the tools are available in the Other category right now, so
I'm not sure this is a blocker by itself)

The current suggestion is to add a Settings category in the menus;
however, I'm unsure how well this works with the fact that it won't show
what's in the gnome-control-center... Any opinion?

The alternative is to just leave Other, and push people to move the
items there in more appropriate categories.
=====

FWIW, I'm leaning towards just leaving the Other category and living with it.
Comment 21 Jasper St. Pierre (not reading bugmail) 2013-02-02 02:51:01 UTC
Is this still A Thing?
Comment 22 Adam Williamson 2013-02-02 03:06:02 UTC
Yeah, it still is A Thing. In Fedora, all the system-config-* tools show up in the Other group, still. This is one of those things that never quite bubbles up to the top of my todo list...
Comment 23 Adam Williamson 2013-02-02 03:06:54 UTC
ideally we'd just kill all the system-config-* tools, but that's not entirely practical yet, though we're getting there.
Comment 24 Jasper St. Pierre (not reading bugmail) 2013-02-02 03:13:11 UTC
(In reply to comment #23)
> ideally we'd just kill all the system-config-* tools, but that's not entirely
> practical yet, though we're getting there.

Sounds like the correct fix.
Comment 25 Adam Williamson 2013-02-02 03:21:59 UTC
It's not something we can really do overnight, there's still several with no full replacement:

system-config-lvm
system-config-printer
system-config-firewall (still needed for non-firewalld configs)
system-config-date (not sure if the GNOME one can be applied systemwide, and it definitely can't do system-clock-as-localtime/system-clock-as-UTC)
system-config-kickstart (that's pretty Fedora-specific)
...

it doesn't really look like we'll be able to kill them all any time soon. I think the recommendation that GNOME handle the 'Settings' category and then we fiddle with the Fedora .desktop files is probably the most practical. I should check if GNOME started handling Settings, actually.
Comment 26 André Klapper 2021-05-25 12:46:05 UTC
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.