On Tue, 2007-11-20 at 10:47 +0100, Nils Philippsen wrote: > > Actually for home/consumer desktop use, there is not much need for any > > of the system-config-* tools any more; for example for F9, intlclock > > will replace system-config-date > > ... as the tool that is launched when you click on your (GNOME) panel > clock -> "Adjust Date & Time". I don't see s-c-date going away anytime > soon (as the maintainer I'm a bit biased), at least as long as the DE > specific tools are full replacements. I'm pretty sure that Rawhide intlclock launches code shipped with intlclock when you press "Adjust Date and Time". If it doesn't that's a bug. FWIW, this is what it looks like http://people.freedesktop.org/~david/intlclock-change-time.png Yes, this is in contrast to previous Fedora releases where s-c-d was used. > Well, the idea of "whatever upstream" is most appealing to me as that > can as well be us ;-). Certainly. Keep in mind that Red Hat / Fedora are already upstream for a lot of important key projects http://fedoraproject.org/wiki/RedHatContributions So.. the key to participating in upstream projects is just that.. participating. Integrating features into where it makes sense; e.g. for GNOME the clock applet and NetworkManager for the NTP bits. Ideally the mechanism used by intlclock is independent of the UI (intlclock will probably switch to fd.o system tools [1]) so it's easy for people from KDE, XFCE, etc. to write their own UI shells. And, heck, why the hell not a TUI version too. All using the same mechanism. All benefiting from a huge pool of contributors across the free software OS landscape; not just Linux, also OpenSolaris. Which is, and sorry if this comes across as a flame, in contrast to having a stand-alone monolith e.g. system-config-date. [1] : Formerly (and sorta kinda still) known as gnome system tools > Mind that as configuration tools aren't only > interesting to desktop users we should be careful under which umbrella > (if one) we put them. It's not like anyone suggesting that s-c-d is going away. The change here is that it's not likely to be in the default desktop install. People can still install it and build spins around it and so forth. > I'm with you as far as UI <-> logic <-> privileged > ops separation is concerned. Sounds good. David -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
