This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 697834 - Other menu appears in default installation (any .desktop entry with Category=Settings ends up here (even if there's also Category=System))
Other menu appears in default installation (any .desktop entry with Category=...
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: gnome-menus (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened
: 699422 702176 702178 702431 (view as bug list)
Depends On:
Blocks: F15-accepted/F15FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2011-04-19 07:54 EDT by Elad Alfassa
Modified: 2015-01-09 16:58 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-09 16:58:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch for this (gnome-menus fedpkg patch) (2.82 KB, patch)
2011-05-09 14:00 EDT, Adam Williamson
no flags Details | Diff
alternative patch (3.29 KB, patch)
2011-05-09 14:55 EDT, Adam Williamson
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 645061 None None None Never

  None (edit)
Description Elad Alfassa 2011-04-19 07:54:18 EDT
(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")
 :-(
Comment 1 Adam Williamson 2011-04-19 11:13:52 EDT
before anyone complains about the stupid criteria, this is one that was submitted by the desktop team =)
Comment 2 Tim Flink 2011-04-21 13:48:57 EDT
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.
Comment 3 Ray Strode [halfline] 2011-04-21 14:32:41 EDT
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.
Comment 4 Ray Strode [halfline] 2011-04-21 14:33:57 EDT
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.
Comment 5 Matthias Clasen 2011-04-27 20:18:59 EDT
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.
Comment 6 Adam Williamson 2011-04-27 21:46:21 EDT
if they all have the same stuff in their .desktop file, can't gnome-menus just be changed to handle it?
Comment 7 Elad Alfassa 2011-04-28 00:58:12 EDT
*** Bug 699422 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Clasen 2011-04-29 13:13:58 EDT
(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 ?
Comment 9 Adam Williamson 2011-04-29 13:15:47 EDT
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
Comment 10 Adam Williamson 2011-04-29 13:17:41 EDT
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
Comment 11 James Laska 2011-04-29 14:50:39 EDT
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.
Comment 12 Tomas Mraz 2011-05-05 02:29:54 EDT
*** Bug 702178 has been marked as a duplicate of this bug. ***
Comment 13 James Laska 2011-05-05 08:23:51 EDT
Any decisions on this issue?
Comment 14 Nathan G. Grennan 2011-05-05 13:57:19 EDT
*** Bug 702176 has been marked as a duplicate of this bug. ***
Comment 15 Colin Walters 2011-05-05 18:38:34 EDT
I don't think we can do anything at this point for Fedora 15 on this.
Comment 16 Kevin Kofler 2011-05-05 20:52:11 EDT
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.
Comment 17 Elad Alfassa 2011-05-06 15:01:11 EDT
What's wrong with putting those in system tools? Please explain.
Comment 18 Adam Williamson 2011-05-06 15:02:23 EDT
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
Comment 19 Adam Williamson 2011-05-06 15:04:19 EDT
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
Comment 20 Adam Williamson 2011-05-06 15:05:55 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Kevin Kofler 2011-05-06 15:41:23 EDT
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?
Comment 22 Adam Williamson 2011-05-06 18:04:31 EDT
*** Bug 702431 has been marked as a duplicate of this bug. ***
Comment 23 Adam Williamson 2011-05-06 19:07:54 EDT
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
Comment 24 Adam Williamson 2011-05-06 19:10:04 EDT
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
Comment 25 Matthias Clasen 2011-05-07 14:17:22 EDT
(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.
Comment 26 Elad Alfassa 2011-05-07 14:28:27 EDT
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
Comment 27 Adam Williamson 2011-05-09 11:11:54 EDT
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
Comment 28 Adam Williamson 2011-05-09 11:15:40 EDT
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
Comment 29 Adam Williamson 2011-05-09 13:59:17 EDT
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
Comment 30 Adam Williamson 2011-05-09 14:00:17 EDT
Created attachment 497879 [details]
patch for this (gnome-menus fedpkg patch)
Comment 31 Adam Williamson 2011-05-09 14:06:35 EDT
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
Comment 32 Adam Williamson 2011-05-09 14:54:36 EDT
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
Comment 33 Adam Williamson 2011-05-09 14:55:04 EDT
Created attachment 497892 [details]
alternative patch

alternative and somewhat more elegant patch
Comment 34 Elad Alfassa 2011-05-09 15:00:14 EDT
(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
Comment 35 Adam Williamson 2011-05-09 15:08:50 EDT
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
Comment 36 Adam Williamson 2011-05-09 15:09:14 EDT
elad: that would certainly make it harder to fix it there =)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 37 Adam Williamson 2011-05-09 15:12:38 EDT
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
Comment 38 Matthias Clasen 2011-05-10 06:56:26 EDT
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.
Comment 39 Adam Williamson 2011-05-10 10:59:53 EDT
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
Comment 40 Kevin Kofler 2011-05-10 11:24:10 EDT
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.
Comment 41 Adam Williamson 2011-05-10 11:36:38 EDT
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
Comment 42 James Laska 2011-05-10 11:49:46 EDT
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
Comment 43 Colin Walters 2011-05-10 12:53:00 EDT
(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.
Comment 44 Adam Williamson 2011-05-10 13:06:53 EDT
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
Comment 45 Colin Walters 2011-05-10 13:21:24 EDT
(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.
Comment 46 Adam Williamson 2011-05-10 13:37:22 EDT
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
Comment 47 Adam Williamson 2011-05-10 13:59:25 EDT
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
Comment 48 Adam Williamson 2011-05-10 14:00:13 EDT
adjusting to NTH status, with votes from me, jlaska, mclasen and dgilmore.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 49 Adam Williamson 2012-05-08 21:37:25 EDT
Sadly, this is still valid for 17...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 50 Fedora End Of Life 2013-07-03 23:03:46 EDT
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.
Comment 51 Tadej Janež 2013-08-01 03:16:35 EDT
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?
Comment 52 Fedora End Of Life 2013-08-01 06:04:24 EDT
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.
Comment 53 Tim Waugh 2013-08-01 06:24:10 EDT

*** This bug has been marked as a duplicate of bug 846290 ***
Comment 54 Tadej Janež 2013-08-01 06:59:46 EDT
(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.
Comment 55 Tim Waugh 2013-08-01 07:23:33 EDT
Oops, sorry.
Comment 56 Fedora End Of Life 2015-01-09 16:48:32 EST
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.
Comment 57 Adam Williamson 2015-01-09 16:58:06 EST
I don't think it really makes sense to keep this open now we're all GNOME 3'ed.

Note You need to log in before you can comment on or make changes to this bug.