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

List:       kde-debian
Subject:    Re: Control Center or separate application? Was: Kalternatives 0.2
From:       Dominique Devriese <dominique.devriese () student ! kuleuven ! ac ! be>
Date:       2004-01-03 23:06:07
Message-ID: 87n094ws2o.fsf () student ! kuleuven ! ac ! be
[Download RAW message or body]

Paul Mallach writes:

> Simon Edwards <simon@simonzone.com> wrote:
>> On Fri, 2 Jan 2004 06:57 pm, Juanjo Alvarez wrote:
>>> an HTML view that can include icons and text in a nice layout
>>> explaining what the program launched by those icons do, very much
>>> like the Windows XP control center (which I think is very good,
>>> windows or not).
>> ArkLinux currently has a control center like this. It uses HTML
>> 'screens' with icons, so it's very flexible. The code is GPL
>> IIRC. My first contact with it was via a Mandrake package that
>> Texstar made. He customised and packaged it for Mandrake. I was
>> impressed. :-)

> I quite like that idea as well, but the Control Center is here right
> now and won't go away. I'm quite certain, that it will be reworked
> for next 3.3 release of KDE in one way or the other.

Just for reference, KControl is not here to stay.  I'm sure you didn't
mean this, but there is of course no reason why it could not be
significantly modified or even ( should the need and the better
alternative arise ) replaced in KDE 4 and above.

I always have a lot of plans, but one of the more vague ones atm is to
try and see if I would not be able to help with KControl post-KDE3.2
and post-exams.

What I would like to see is an application that gets rid of the ugly
left navigation pane, to replace it with a more browser-like feel.  I
imagine a KControl showing a list of pretty big icons with cursive,
gray text next to them, like its Windows competition.  If you click
one of the options, you would either be shown the entire KCM
full-screen, or, if you clicked on a sub-category, get to a similar
screen like the first showing you the subentries.  There would be a
back/forward button for navigation and such.  I think we should try to
do this with minimal changes to the API ( existing KCModule's need to
continue working properly ).  I have read some of the discussions
about KControl on kde-usability and other places, and it seems a lot
of people have similar views on the future KControl, I hope it gets
fixed in the future KDE versions.

> Even though I can't see who would reimplement the existing
> kcmodules, this feature request is interesting:
> http://bugs.kde.org/show_bug.cgi?id=71631

> I think these are our options:

> * create a separate container application that contains only our new
>   modules to complenent the CC
>   + can easily embed perl and python modules
>   + can embed stuff like kuser or kcron + we are totally free to
>     design this app and could even use perl/python to code it
>   - CC already contains modules for some aspects of "System
>     Configuration" -> confusion whether an option is in the CC or in
>     the new container app
> * keep control center as it is and include our modules in it 
>   + needs a change in CC, so that python modules will alway be
>     loaded out of the parent process
>   - at this time limited to python / c++
>   - hard to include kuser/... (maybe create a dummy kcmodule that
>     simply spawn the external app)
>   - CC is currently a mess :-)
> * create a separate container application that contains both new
>   and old modules to replace control center
>   + we are totally free to design this app and could even use
>     perl/python to code it
>   - might duplicate work, should CC be reworked into the perfect CC
>     for KDE 3.3 :-)
>   - support-problems because of inconsitency with other KDE
>     distributions (clueless user: "how do i configure my
>     background?", kde god: "use the control center!", cluseless
>     user: "there is no control center!")
> * create a separate container application that contains both new and
>   old modules to replace control center and keep CC for
>   compatibility.
>   + everything we want is possible 
>   + we might be able to embrace and extend the Ark Linux tools :-)
>   - inconsitency with other KDE distributions
>   - two apps that are _slightly_ different is certain to create
>     confusion even if we hide the original CC (which also defeats
>     the purpose of keeping it)
> * fix control center and include our modules in it
>   - time-frame (what exactly is our timeframe?)
>   - we don't know, what the maintainers plans are for 3.3. see the
>     thread on kde-usability I mentioned above

About this discussion, I'd like to add the following points:

1. KControl, KCModules etc. are part of a public API, and this means
   that KDE will definitely not change things in a way that will make
   older third-party KControl Modules unusable.  This can only be done
   for KDE 4, KDE 3.x policy does simply not allow such a
   change. period.  This doesn't mean that nothing can be changed,
   just that we have to design the changes such that this is not
   necessary.  I think this is possible.

2. As has been demonstrated by the KDE Python bindings, it is
   technically perfectly feasible to make KCModule's in other
   languages than C++.  I'm not going to go in to the details ( there
   is a need foe a small bit of boilerplate C++ code to boot up the
   KCM, but that's it ).  Also, implementing GUI modules out of
   process, as has been suggested here is a *very* bad idea.  It has
   been tried in the KControl from KDE 1.x, and it was abandoned for
   the current approach in KDE 2, because implementing focus handling
   and such was a pain ( read kdebase/kcontrol/HOWTO ).

3. As this is a KDE project, I'd like for us to work with the existing
   KDE solutions, and try to avoid the NIH syndrome.  We also want to
   benefit KDE as a whole, and imho, the best way to do this is to
   improve upon KControl, not ditch it.

> Maybe someone should contact the Control Center maintainer
> molkentin@kde.org and ask him, what his plans are and if he would
> accept patches that make the big changes that are required. I'm not
> quite sure, where these should be discussed (kde-usability?)

> Personlly I think it would be best to stay compatible to CC with all
> newly created modules and help to fix the problems with the current
> CC if the current maintainer is willing to accept patches. A new
> container application developed with python could serve as a proof
> of concept.

I don't think you can ask someone "We'd like to make a lot of changes
to your app, we're not really sure what they are yet, how they would
be implemented, or who would do it, but would you accept them ?".  I
can predict you his answer, if you like.  "I'll accept any patches
that are properly implemented, don't break backwards compatibility,
and that generally improve upon KControl".

> when it comes to system configuration I think that a lot of people
> are quite knowledgeable with scripting languages AND system
> configuration/management but are not so well versed in C++.

Please see my above comment about KCM's and other languages.

Note: the above is all IMHO, of course.

cheers
domi
_______________________________________________
kde-debian mailing list
kde-debian@kde.org
https://mail.kde.org/mailman/listinfo/kde-debian
[prev in list] [next in list] [prev in thread] [next in thread]