https://lists.fedoraproject.org/pipermail/desktop/2012-March/007530.html Quoting from this thread: > <adamw> elad661: it's called 'system-config-date' because it was > previously called Date and Time. see the problem with that? > <elad661> yes, I do > <elad661> but I think we could either remove it (since gnome's control > panel provides the functionality) or find a better name. > <elad661> we probably need it for firstboot, so removing the desktop > file might be a good idea Since this application provides the same functionality, (with a much less user friendly interface) as GNOME's control panel (and I'm quite sure other desktops has their own time control panels nowdays), I suggest removing the desktop file. If other desktops (ie. not gnome) still uses this, I suggest moving the desktop file into a subpackage, so it won't be installed on GNOME only machines.
"and I'm quite sure other desktops has their own time control panels nowdays" I'm not entirely sure that's a safe assumption. I don't *think* LXDE has a clock/date app, for instance. It seems much safer to just add NotShowIn=GNOME to the .desktop file, as far as GNOME is concerned. Other desktops can do the same if they wish. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think we are facing two different problems here: 1. The menu entry is not localized 2. If we use "Time and Date" again, we end up with the same name twice in GNOME. How about hiding the entry in GNOME with "NotShowIn=GNOME;". No big deal because gnome-control-center provides most of the functionality (except ntp configuration). For more background see bug 744535.
(In reply to comment #1) > "and I'm quite sure other desktops has their own time control panels nowdays" > > I'm not entirely sure that's a safe assumption. I don't *think* LXDE has a > clock/date app, for instance. Correct, neither Xfce not LXDE can configure the system-wide date and time settings. Not sure about KDE. The problem we are facing is that GNOME no longer follows the freedesktop.org standards they created some years ago. Instead of Name they now use X-GNOME-FullName. I don't think other desktops who follow the standards should suffer from that - especially since GNOME doesn't need system-config-date any longer.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Would it be possible to make system-config-date a dependency of these other DEs? The launcher isn't needed under GNOME and duplicates functionality that is already found in System Settings.
A dependency does not make sense, people should still be able to decide whether they want system-consif-date or not. "NotShowIn=GNOME;" should be sufficient, but then it will be hidden even for GNOME users who want to have it, e.g. because it allows them to configure NTP with gnome-control-center does not.
The presence of system-config-date in the desktop image degrades the user experience by including an unnecessary launcher and by confusing the role of System Settings. It's really important that we make the default desktop experience as good as it can be. (In reply to comment #6) > A dependency does not make sense, people should still be able to decide > whether they want system-consif-date or not. Setting the time and date of the system seems like essential functionality; is it really a bad idea to ensure that it's always present? > "NotShowIn=GNOME;" should be > sufficient, but then it will be hidden even for GNOME users who want to have > it, e.g. because it allows them to configure NTP with gnome-control-center > does not. Right, that's my concern about hiding the launcher under GNOME.
Why not just remove it from the desktop spin?
(In reply to comment #8) > Why not just remove it from the desktop spin? Sounds good to me. :)
Looking at the F18 package set, assuming InitialSetup exists, this should more or less just happen by default - s-c-date would fall out of the desktop spin, as the only thing that would bring it in would be firstboot.
Why would firstboot need system-config-date now that you can set date&time in anaconda itself? if it's only for the OEM usecase, we should probably make s-c-date integration with firstboot optional and not mandatory. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
As both system-config-date and firstboot are optional now, this doesn't seem an issue to me anymore (you can always opt to not install s-c-date), I'll close this now. Whether or not firstboot should require s-c-date is not my call.
That's really not much use. In practice our default release (the desktop live) and our default install from DVD or netinst both install s-c-date and firstboot. This needs to be open, though re-assign it if you want.
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.
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.