[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:       Paul Mallach <pm () ariva ! de>
Date:       2004-01-02 23:40:02
Message-ID: opr059c0zppao430 () 10 ! 0 ! 0 ! 1
[Download RAW message or body]

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.

For discussion regarding the CC, see this thread on KDE Usability:
http://lists.kde.org/?l=kde-usability&m=107229252300655&w=2

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

So basically:

roll our own:
- good: hopefully better usability, can integrate perl/python modules and 
existing apps,
  could serve as a testbed for a next-gen KDE CC
- bad: inconsistent with other KDE desktops, should KDE 3.3 contain a much 
improved CC then we might want to switch back to the distributed KDE

use existing CC:
- the good: consistent with KDE, we can use all improvements made in the 
KDE 3.3 cycle
- the bad: usability problems, no integration of perl modules / existing 
apps

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.

>> The reason for me developing right now in Python is that I'm about 4
>> times more productive on it than on C++ and debugging is a lot less
>> painful (python tracebacks rule).
> Wonderful isn't it. :)
Oh, well in fact Python sucks and Perl rules, but I guess you already know 
that. :-)

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++.

Having spent years coding in a number of languages I could hack together 
some C++ module with the good old copy and modify method, but to become 
really proficient with the language would take me quite some time. Time 
that I would rather spend coding unless someone can convince me, that C++ 
is the ultimate language for
system configuration.

bye, Paul.

_______________________________________________
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]