[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mandrake-cooker
Subject:    Re: [Cooker] Suggestions for Mandrake 10.1
From:       Juan Luis Baptiste <juancho () phreaker ! net>
Date:       2004-05-31 4:18:50
Message-ID: 200405302318.51209.juancho () phreaker ! net
[Download RAW message or body]

On Sunday 30 May 2004 21:28, Richard Neill wrote:
> Austin Acton wrote:
> > On Sun, 2004-05-30 at 20:58 -0400, Rob wrote:
> >>We have separate "Configure your desktop" and
> >>"Configure your system" entries in the start-menu-equivalent,
> >>and then on top of that, right-clicking on the desktop and
> >>clicking "Configure desktop" brings up something different than
> >>the menu item does.
>
> Actually, (in my view, anyway), this isn't such a bad thing. The KDE
> settings are *mainly* things that affect individual users, whereas the
> MCC things are all system-wide. Of course, for a desktop system, this
> distinction isn't so important.
>
> You might also like to consider that there is an overlap in
> functionality between KControl and MCC for some tasks. (eg Kups vs
> PrinterDrake) If you merge them, which do you remove?
>
> Anyway, I don't think that such a merge could ever happen, because
> people will need access to MCC whether they have KDE, GNOME, or even
> just ncurses (no X).
>

I agree, but there's an approximation to have a common set of "administration 
tools" with native GUI's for GNOME and friends (made in GTK), and for KDE 
(made in Qt). There are the Gnome System Tools [1], which provide 
administration tools for GNOME to configure things like internet connection, 
users, services, date and time, etc. GST is divided in frontends, a bunch of 
GTK GUI's, and backends, that are who actually do the dirty job (in a 
platform independent way, but that in this case doesn't matter). The 
frontends and backends communicate using XML files. Having a tool structured 
this way is great because it allows to have different GUI's made in anything 
you want, for example Qt. As a proof of concept, I have been developing a 
tool to configure the network settings from within KDE, using the network 
backend of GST, it's name is KNetworkConf [2] (you can install it from 
contribs), and it's development was some sort of faster because all the 
coomplicated things of managing the network settings where already made for 
me in the network backend. The cvs version is now a kcontrol module that 
integrates nicely [3] into KDE Control Center. 
My point is, MCC could be developed in a similar way to GST, divided in front 
and back ends, so the actual MCC GUI can be reused but it could allow to 
develop a Qt GUI for KDE very fast, so everybody would be happy :-). It could 
be better if MCC used GST backends (maybe the frontends too?) and port the 
GUI to use it, and start implementing the tools for KDE using the same 
backends (and you would have one tool already done ;-)). If Mandrake choose 
to use this approach for MCC, I'll be the first person to start coding the 
drak* tools for KDE :-D.

[1] http://www.gnome.org/projects/gst/
[2] http://knetworkconf.sf.net
[3] http://knetworkconf.sourceforge.net/Screenshots/0.6/kcm_knetworkconf.png


Cheers,
-- 
Juan Luis Baptiste
http://www.merlinux.org
http://knetworkconf.sf.net


[prev in list] [next in list] [prev in thread] [next in thread]