Re: PROPOSAL : Integrating system tools in GNOME



> Then it is obviously not advertised or used correctly or its
architecture
> doesn't inspire the OS makers to endorse it. I have yet to see anyone
except
> Ximian using the framework (I think RH uses python and their own
backend
> thing and Mdk their own thing too using gtk-perl).

I personally think that the problem with gnome-system-tools is a bit
different. Currently, the backend is very tied in into the frontend (I
don't mean codewise, since I don't really know about that, but rather
from the way the project is presented etc...). I think that if the
backend is ripped out, and made to get some kde buy-in (KST for the KDE
centric distros?), and also have a curses frontend, then distros would
prefer to support this semi-universal backend. That way they write one
backend (should be a few Perl/Python scripts) and then people can use
any number of tools from any DE or frontend to configure their system,
and they arn't tied into Gnome/GTK.

Infact, if the backend gets ripped out enough and made into a
semi-library, this could be the way GNOME and KDE can provide the
integration with the system, that until now have been done with hacks
and distro specific patches.
Say the library could have a way of getting if a user has permissions to
reboot/shutdown (for the logout dialog).
Or if a user has permissions to activate/deactivate/configure a network
device, and allowing applets like the network monitor to do those things
(I know fedora has something like that, but only with regards to
activation)

Basically, what I am trying to say is that I think there will be a
bigger distro buy in if the backend gets used much more beyond the
gnome-system-tools. Currently, as other people said, for most distros
there just isn't a point.

P.S. Sorry Eugenia for accidentally sending this to you separately

Daniel




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]