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

On Mon, 2007-11-19 at 16:37 +0100, Nils Philippsen wrote:
> On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
>
> > Just wondering: Why don't we work towards getting some sane config tools
> > (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> > interest)? Sure, that way other distros will benefit from out work as
> > well, but on the other hand having stuff as de-facto part of Gnome and
> > used by other distros afaics lead to better tools and a better user
> > experience, which overall leads to a better "Linux".
>
> AFAIK, some stuff, e.g. date and time setting via the time applet,
> creating users, is already worked on for GNOME. Whether these will cover
> all aspects (e.g. also server specific stuff), I don't know. Whether
> these should cover non-desktop aspects at all can also be disputed ;-).
>
> Certainly, once UI and logic of the existing tools are sufficiently
> separated the logic could be used from applets/tools more tightly
> integrated into the desktop environment of choice if there's the need.

Might be worthwhile to point out that there is prior art in this area
with gnome-system-tools. They already have the ui/mechanism split and
are moving towards adopting PolicyKit. The traditional complaint about
them has been that they have no distro adoption, but I recently learned
that probably at least Debian/Ubuntu, Gentoo and FreeBSD are using them
nowadays.

There are admittedly a few warts:
- the backends used to be written in perl (not sure if that is still the
case)
- they follow the kitchen-sink approach of keeping everything in a
single system-tools-backends package

If we are talking about cross-distro collaboration for traditional
system-config tools, that may be the leading contender.

What we in the desktop team want to push a little further in F9 is to
move some system configuration tasks into the regular tools where that
makes sense. An early example of that is the time+timezone setting
inside the clock applet, other examples to follow will be a "Use these
settings system-wide" button for the power management preferences and
some other areas where it makes sense. Access to this will be controlled
via PolicyKit as well.


Matthias


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
> Just wondering: Why don't we work towards getting some sane config tools
> (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> interest)? Sure, that way other distros will benefit from out work as
> well, but on the other hand having stuff as de-facto part of Gnome and
> used by other distros afaics lead to better tools and a better user
> experience, which overall leads to a better "Linux".

This is actually what we've been working on in the RH/Fedora desktop
team for quite some time. The mantra here, as you point out, is both
"upstream", proper separation of the user interface and the mechanism,
access control and, ideally, integration with directory services such as
the Fedora Directory Server.

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 and Søren's work on xrandr UI will
probably be able to replace most of system-config-display. The former,
at least, is getting merged into upstream GNOME as we speak. The latter,
I believe, will be proposed for GNOME as well. Søren?

As for server use... e.g. s-c-httpd and friends I'm not sure. I've
always found it rather odd to use an UI for this in the first place but
I do acknowledge that some of our users find this useful. It's
definitely something that is on the check-list of many system
administrators especially those from the Windows world.

In my opinion, the most important thing to fix with our remaining
system-config-* tools is to get upstream buy-in (ideally merge it into
GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
mechanism and use things like PolicyKit for access control. Notably, Tim
is doing a pretty good job here with s-c-printer; that's why Ubuntu got
the best printing support on the planet :-) [1]

David

[1] : I'm being sarcastic because space boy doesn't always give credit
where credit is due. Sources have told me that someone is working on
"fixing" this problem though


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

On Mon, 2007-11-19 at 12:28 -0500, David Zeuthen wrote:
> On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
> > Just wondering: Why don't we work towards getting some sane config tools
> > (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> > interest)? Sure, that way other distros will benefit from out work as
> > well, but on the other hand having stuff as de-facto part of Gnome and
> > used by other distros afaics lead to better tools and a better user
> > experience, which overall leads to a better "Linux".
>
> This is actually what we've been working on in the RH/Fedora desktop
> team for quite some time. The mantra here, as you point out, is both
> "upstream", proper separation of the user interface and the mechanism,
> access control and, ideally, integration with directory services such as
> the Fedora Directory Server.
>
> 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.

> and Søren's work on xrandr UI will
> probably be able to replace most of system-config-display. The former,
> at least, is getting merged into upstream GNOME as we speak. The latter,
> I believe, will be proposed for GNOME as well. Søren?
>
> As for server use... e.g. s-c-httpd and friends I'm not sure. I've
> always found it rather odd to use an UI for this in the first place but
> I do acknowledge that some of our users find this useful. It's
> definitely something that is on the check-list of many system
> administrators especially those from the Windows world.
>
> In my opinion, the most important thing to fix with our remaining
> system-config-* tools is to get upstream buy-in (ideally merge it into
> GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
> mechanism and use things like PolicyKit for access control. Notably, Tim
> is doing a pretty good job here with s-c-printer; that's why Ubuntu got
> the best printing support on the planet :-) [1]

Well, the idea of "whatever upstream" is most appealing to me as that
can as well be us ;-). Mind that as configuration tools aren't only
interesting to desktop users we should be careful under which umbrella
(if one) we put them. I'm with you as far as UI <-> logic <-> privileged
ops separation is concerned.

Nils
--
Nils Philippsen / Red Hat / nphilipp@redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list