(from bug #685142 Comment 16) >Actually the current fix is a bit problematic, because it will cause showing >the Other menu in default installation, and it's against the final release >criteria: https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria We need an administration category, or to move all administration utilities to system tools (make sense IMO). See also: https://bugzilla.gnome.org/show_bug.cgi?id=645061 Otherwise it is a blocker (criteria: "There must be no Other menu or category") :-(
before anyone complains about the stupid criteria, this is one that was submitted by the desktop team =)
Discussed at the 2011-04-21 blocker bug review meeting. This very clearly hits the following final release criterium: "There must be no Other menu or category " Accepted as F15 final blocker.
I think fixing this isn't really as straight forward as a small change in a .directory or .menu file or anything like that. We need to look at each of these icons one-by-one and figure out why they are there and if they should be there at all. It's something we should have done a long time ago actually (even pre-GNOME 3). For instance, system-config-users (for the default use cases) is redundant compared with whats shipped in control center. There may be more advanced cases where system-config-users is useful, but those are "not by default" cases so system-config-users shouldn't show up in the menus by default. If the user does install system-config-users throwing it in "Other" seems wrong to me. It should probably go in "System Administration" or some such (not "Administration", though, since then it will end up at the top of the list). So to summarize 1) For many administrative tasks, the control center panels are the way to go. This should be our "by default" story 2) For more complicated cases that are outside the scope of control-center panels some of the system config tools fill a valuable role and those cases should be "opt in after install" for the user 3) If the user does "opt in" we need to make sure the thing they install is sensibly categorized.
I think an implication of this is we should have a "System Administration" category but it should be hidden in the default install and only show up after the user has installed system-config tool explicitly.
We do actually have a system administration menu now in the shell; but Other is still there and well-popuplated. I know that we've put this in the release criteria at some point, but I don't think fixing it for F15 is feasible at this time; too many individual desktop files to change.
if they all have the same stuff in their .desktop file, can't gnome-menus just be changed to handle it?
*** Bug 699422 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > if they all have the same stuff in their .desktop file, can't gnome-menus just > be changed to handle it? Well, you have to ask yourself if you want to have meaningful categories in desktop and menu files, or if you just want to have it 'look right' in the shell ?
well, they _do_ have meaningful categories, which caused them to appear in sensible places in f14. aiui, nothing changed in the .desktop files; something changed in gnome-menus because someone wanted to kick these apps out of the menus. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
afaics all the system-config-* tools have "Categories=System;Settings;" in both F14 and F15. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at 2011-04-29 blocker review meeting (http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-29/f15-blocker-review.2011-04-29-17.00.html). Discussing adjustments to the stated desktop menu criteria, which may lower the importance of this bug. Should the 'Other' menu no longer be required, please remove the release criteria before de-escalating this issue.
*** Bug 702178 has been marked as a duplicate of this bug. ***
Any decisions on this issue?
*** Bug 702176 has been marked as a duplicate of this bug. ***
I don't think we can do anything at this point for Fedora 15 on this.
Settings is a standard category in the freedesktop.org desktop file spec, so it is a bug in gnome-shell if it can't handle that category. Moving the entries to some other arbitrary category or hiding them will break other desktops which comply to the freedesktop.org standard. That said, using both Settings and System to be put under Administration is a Fedora-specific hack which needs to go away. If we use the upstream KDE menu categories in KDE Plasma, the Kickoff menu will do the most sensible thing by the spec and just show it in both places. (There is no Administration menu in upstream KDE.) We used to carry a patch which adds an Administration menu to Kickoff up to Fedora 14, but we have pretty much decided not to carry that anymore in Fedora 15. See bug 701693 for the reasons. Desktop files should list exactly one primary category, and gnome-shell should have categories to map all the primary categories defined by the standard to.
What's wrong with putting those in system tools? Please explain.
I'm still unclear on why this is such a problem. the System Tools entry in /etc/xdg/menus/applications-gnome.menu has this: <Include> <And> <Category>System</Category> <Not><Category>Settings</Category></Not> </And> </Include> but there's no comment to justify this; _why_ do we explicitly exclude things with the category Settings from the System Tools menu? I can't see any reason for that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
it seems like it may be in there because in the past we wanted to do something special with things that have category System *and* Settings, but that's no longer the case - so why not just remove this exemption from applications-gnome.menu and let them turn up in System Tools? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I don't think stuff should have both System and Settings in the first place. They're both primary categories according to the spec, one primary category is sufficient. Listing both categories will lead upstream KDE's menu to list the files twice, and IMHO we'd rather not continue carrying the patch to our kdelibs packages we carried up to F14 because then we rely on the now deprecated redhat-menus to get a translated name and an icon for the non-upstream category, or we'd have to carry (and maintain!) the translations inside the kdelibs patch. One workaround would be to arbitrarily assign the entries to System or Settings using a snippet like the one from comment #18, but shouldn't it be the .desktop file to decide which is more relevant? By the way, is the problem in gnome-shell really only the stuff with BOTH System and Settings as categories? Where do entries with only Settings (which is a primary category of its own) end up?
*** Bug 702431 has been marked as a duplicate of this bug. ***
Kevin: We all agree on that, AFAICT, but desktop team say they don't want to fix that many packages before F15 (I'm not sure why since it's a single well-understood change that'd take about fifteen minutes to do across all affected packages, but hey). I'm looking at how to address it for F15 given the assumption that the .desktop files won't change. "By the way, is the problem in gnome-shell really only the stuff with BOTH System and Settings as categories? Where do entries with only Settings (which is a primary category of its own) end up?" Short answer, I'm not sure, and it may well be that they end up in Other too (I can't see any *positive* reference to Settings in applications-gnome.menu (or applications.menu , for that matter), only <Not> references excluding it from various places. But we know for _sure_ that things with both categories are affected. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Okay, found an example... /usr/share/applications/itweb-settings.desktop specifies only: Categories=Settings; and it shows up in the Other category. So we can say that, as well as things with System and Settings categories being specifically excluded, the current Shell menu layout does not account for the Settings category at all, despite it being a standard category per the spec. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #24) > and it shows up in the Other category. So we can say that, as well as things > with System and Settings categories being specifically excluded, the current > Shell menu layout does not account for the Settings category at all, despite it > being a standard category per the spec. We can say all kinds of things, but the important statements are in comment 5 and comment 15.
I don't see a system administration menu, and I don't see *anything* that comes in the default install that is in Other menu and is not system settings related. (all items the default install has in Other are system administration. Actually there are two items there that aren't related to system and only related to settings, but one of those is going to be removed, see bug #701888). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
mclasen: it would be nice to have a *reason* why you think it's so dangerous to fix an obvious flaw in GNOME's menu layout. There's no plausible reason for the entire Settings category to not be handled. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
matthias: in comment 5 you claim there are too many .desktop files to change; I've already pointed out that we don't need to change any. All we need to change is about three lines in gnome-menus, to account for all the apps currently under Other. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So, I'm attaching a patch to gnome-menus package which fixes this, by making anything in System or Settings categories show up in System Tools. It also has an exclusion for X-GNOME-Settings-Panel to make sure nothing from control-center shows up there. I think the reason for the exclusion was to make the apps with both System and Settings show up in an 'Administration' sub-menu of the 'System' menu in GNOME 2's default three-menu layout (Applications, Places, System). I think that's what the system-settings.menu file in /etc/xdg/menus is supposed to do. But with GNOME 3 we just don't have that layout any more, in Shell or fallback mode. Dumping them all in System Tools isn't necessarily the optimal solution; that category's quite large and has a lot of garbage in it, so in fallback mode it gets quite big and messy. But I think it's still better than having an 'Other' category. An alternative would be to re-create the Administration sub-menu (under Applications, in fallback mode) and put them in there instead; I can supply a patch that does that instead if desired. I tested this in Shell, fallback mode, LXDE and Xfce; it doesn't make things worse in any of those. LXDE and Xfce retain their sub-menus with these apps in them (they don't fall into System Tools in those desktops), so that's okay. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 497879 [details] patch for this (gnome-menus fedpkg patch)
it seems like basically, with Shell and GNOME 3 fallback, all the stuff done by /etc/xdg/menus/settings.menu is kinda lost. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Here's an alternative patch, which more or less adds the Preferences and Administration categories from system-settings.menu and preferences.menu - which are part of redhat-menus - to gnome-menus' applications.menu . There's kind of a jurisdiction issue here - it's not clear to me whether we should change this in gnome-menus or redhat-menus, and exactly how it should happen, because there's kind of two factors in play here: this is pretty GNOME-specific, which suggests it should be in gnome-menus and not redhat-menus (which should presumably be desktop-agnostic), but otoh, it's partly Fedora-specific (with the use of 'System + Settings = Administration', which is a Fedora-ism) so it should be in redhat-menus and not a patch to gnome-menus which comes from upstream. It's a bit murky and could probably do with a bigger overhaul. But for right now, this achieves in practice what I think is the most elegant fix: both Shell and fallback mode get Administration and Preferences menus back, with what was in them in F14 there, except that now bits of the Control Center are excluded from appearing in the Applications menu, which I gather is intended. I can rework this to happen in redhat-menus if it's thought that would be more appropriate. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 497892 [details] alternative patch alternative and somewhat more elegant patch
(In reply to comment #32) > There's kind of a jurisdiction issue here - it's not clear to me whether we > should change this in gnome-menus or redhat-menus, AFAIK gnome 3 doesn't use redhat-menus at all. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
probably in the long-term we would want gnome-menus upstream to grow a category for Settings, since that's part of the XDG spec, and we would want to drop the Fedora-ism that 'System' plus 'Settings' equals 'Administration', because that's not at all part of the XDG spec; we should adjust all the things we categorize that way to be more in-line with upstream. Ultimately we should be able to rely entirely on gnome-menus and ditch redhat-menus. but that's not f15 stuff. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
elad: that would certainly make it harder to fix it there =) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
sorry to keep thinking aloud, but another way to do this would be to add _only_ the 'Preferences' menu to gnome-menus, covering anything with category 'Settings'. That would be upstream-able, as gnome-menus should cover that category anyway. We'd lose the Administration menu and all that stuff would go into Preferences, but hey, it still beats putting them under Other or System Tools. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Right, so what we've been doing essentially since forever (at least since the Bluecurve era) is to equate System+Settings = system-wide settings, system-config tools Settings = user preferences, gnome-control-center capplets and the like Part of the problem is that 'System' is a somewhat unfortunate name for a category, so it ends up containing lots of random stuff.
yeah, I've never liked that as a top-level category either. But for now, for F15, what do you think of resolving this using either my second patch or the idea in comment #37? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
FYI, the next kdelibs build for F15 is going to have the Administration menu readded (with a Requires: redhat-menus this time so we get proper naming including translations and a proper icon; the real problem in bug 701693 was that redhat-menus was no longer dragged in by anything in F15), so the stuff with both System and Settings as categories gets put somewhere sensible. But in the long run we should really treat primary categories as the spec intends, i.e. pick only one unless you WANT the entry to be listed twice.
oh, yeah, we should add Requires: redhat-menus on top of my patch if taken, thanks kevin. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The desktop release criteria in question were discussed on test@ [1] and there is agreement that the 'Other' menu was more a symptom of a possible failure in the GNOME2 world, but not a hard criteria (esp in light of GNOME3's use of those menus). If we remove that F15 final release criteria, it seems sensible to downgrade this issue from a Blocker to a Nice-to-have (NTH). As a NTH, the choice of resolution is up to the maintainer. They can decide to do nothing, or accept the patch posted by awilliam. -1 Blocker, +1 NTH [1] http://lists.fedoraproject.org/pipermail/test/2011-May/099787.html
(In reply to comment #3) > 2) For more complicated cases that are outside the scope of control-center > panels some of the system config tools fill a valuable role and those cases > should be "opt in after install" for the user I'd say generally we want to steer complex cases towards documenting how to do things in the relevant config files. (In reply to comment #29) > > Dumping them all in System Tools isn't necessarily the optimal solution; that > category's quite large and has a lot of garbage in it, so in fallback mode it > gets quite big and messy. But I think it's still better than having an 'Other' > category. That's the root of this - sure, "Other" is ugly, but it's not clear to me that System Tools is compelling either. I guess it's slightly less embarrassing. So...if we were going to do something here I'd prefer the first patch from comment 30 over adding two new categories.
How would you feel about comment #37? That would be upstreamable, as gnome-menus ought to account for the top-level 'Settings' category from the fd.o spec, and at present it does not. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #44) > How would you feel about comment #37? That would be upstreamable, as > gnome-menus ought to account for the top-level 'Settings' category from the > fd.o spec, and at present it does not. If we're talking about changing GNOME, that should happen here: https://bugzilla.gnome.org/show_bug.cgi?id=645061 For Fedora 15, I'd still prefer the known hack of putting them in System Tools; it's a simple patch and seems clearer to me than pulling in parts of redhat-menus.
well, doing what's in comment #37 would barely be pulling parts of redhat-menus - all it'd be doing is defining a menu called Preferences and putting anything from the Settings category in it. I'm really just trying to think of a way to fix this that is simple, correct per fd.o spec, and upstreamable to gnome.org; adding a single menu for the Settings category seems to meet all those criteria. Anyway, I'll throw in a patch that does that, and you can choose what to do: you can pull any of the three patches and submit an update, or you can do nothing. As this is an NTH bug now we don't require a fix, it's up to maintainer's discretion. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I just noticed that Settings.directory is missing from f15 redhat-menus, for some reason, which sucks. We'd have to put that back in to get a Preferences menu with proper translations. Maybe we should just go with patch #1 after all, at least it's simple. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
adjusting to NTH status, with votes from me, jlaska, mclasen and dgilmore. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Sadly, this is still valid for 17... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This problem is still present in F18. In F19, GNOME Shell UI removed the visibility of categories and introduced a new concept: AppFolder. By default, it provides two AppFolders: Utilities and Sundry. So in some way, Sundry replaces the Other category. After a default installation, Sundry contains ABRT, setroubleshoot, firewall-config, etc. But if you install some 'old-school' system configuration tools (e.g. system-config-date, system-config-firewall), they will also be added to the Sundry AppFolder. Is this still an issue or not?
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
*** This bug has been marked as a duplicate of bug 846290 ***
(In reply to Tim Waugh from comment #53) > > *** This bug has been marked as a duplicate of bug 846290 *** I've read through the bug 846290's comments but I fail to see how this bug is a duplicate of that. If anything, it is a super-set of that bug.
Oops, sorry.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I don't think it really makes sense to keep this open now we're all GNOME 3'ed.