and once again... a better cvs structure, clearer dependancies, more logic :-) Was: Refactoring KCM technology

[Alexander Neundorf]

On Monday 22 March 2004 06:48, Cornelius Schumacher wrote:

[... skipped many good arguments, nothing to add]

All the following suggestions are intended for KDE 4, not 3.3, so here we go:

> Nothing, as well as you can't use another language as english,
> applications needing some kioslaves won't run (e.g. KMail or
> KHelpcenter), you can't configure aspects of the applications which
> need kcontrol modules from kdebase, etc.
>
> Face it: kdebase is required to run KDE applications. 

Well, but it also features a lot of things not required to run other 
applications: kicker, kwin & styles, kdm, kfind, kpager, kdesktop, 
kappfinder, kdcop, klipper, kmenuedit, ksmserver, kscreensaver, ksplash, 
ksysguard, kxkb, legacyimport, ksystraycmd, ktip

> If you try to move all the stuff which is needed to kdelibs you will 
> effectively move half of kdebase which certainly is not what we want.

Actually: why is it not what we want ?

If stuff in kdebase is library-like framework, it might go into kdelibs.
Currently kdebase is a mixture of framework stuff (ioslaves, kdesu, 
khelpcenter, kdialog), kde desktop apps (kicker, kwin and the ones listed 
above) and some selected basic applications (konsole, kfind, konqueror, 
kate).

Why is there so much resistance to clean this mixture and get some better 
structure again ?

IMO better would be: 

kdelibs: basically as it is now: something very stable, absolutely essential, 
where it is not easy to change/add things, a module which *shall not* be 
split, also not by packagers, which isn't bloated, which you can rely on if 
you only want some basic kde integration for your (maybe even commercial) Qt 
app or in a resource-constrained environment. Maybe new features should only 
go into kdelibs after they have been for one minor release in the 
kdeframework module and proven to be good/useful. It could even have a slower 
release cycle then the rest (but this probably doesn't make sense with the 
kde development style).

kdeframework: the apps discussed here, ioslaves, and e.g. libs like kabc 
(currently in kdelibs), libkipi, taglib, maybe libkcddb,  the ical stuff from 
kdepim. This way more apps can benefit from the libraries which are currently 
in the various modules. This would resolve most dependancy issues. This 
module could/should be split by packagers into the various components.
Maybe it could also serve as a playground for new libraries or new features in 
libraries, which might be explicitely marked as "experimental" and removed in 
later versions if they turn out to suck, or move to kdelibs if the kick ass 
and are of general use :-)

kdebase: a set of basic applications (konsole, kate, konqy, kfind, kpdf, 
kghostview, an image viewer, kmix, ...)

kdedesktop: depending on kdebase, containing kicker, kwin and stuff (listed 
above)

The other modules should basically stay as they are, maybe some things (libs) 
can move to kdeframework, and some things can move to kdebase...

I think now, before the development for 4.0 starts, is the only chance for 
such a change for the next maybe 3 to 5 or even more years. 

So, the effort of recompiling a lot of things for many developers shouldn't be 
the knock out for having a better structure for our monster pet project for 
the next decade :-)

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net