working with gnome project/other distros together on system tools (was: Re: System-config Reworking Proposal)

[David Zeuthen]

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