KDE 4 modules structure (again)

Alexander Neundorf neundorf at kde.org
Wed Mar 17 18:27:01 GMT 2004


On Wednesday 17 March 2004 18:00, David Faure wrote:
> On Wednesday 17 March 2004 17:22, Dominique Devriese wrote:
> > Again: splitting up on an app- or lib-level reduces dependency
> > problems ( no more moving stuff from kdenonbeta to elsewhere
>
> That means no more quality control. Right now an app is only moved
> to a released kde module when it's good enough, which ensures a
> certain level of quality. If people would just go ahead and create one
> module per app from the start, users would have no idea what's good
> and what's bad, within kde. Currently it's quite clear: when you use
> something from kdenonbeta, you know the risks you're taking.
>
> > no more moving other stuff around
>
> The problem with moving is CVS's limitations, not the fact that we
> sometimes need to move stuff.
>
> > no more not using stuff because it's in the
> > wrong module ( KDE-Edu is already waiting for a long time for
> > KNewStuff to kdelibs ) etc.
>
> Oh joy. Not even a kdelibs anymore? Independent libs? Oh I do not want
> to imagine the number of version checks in the configure scripts and
> the amount of possible combinations of lib versions etc. etc.
> Does kparts-3.3.5 work with kio-3.2.42, or does it need kio-3.2.43+?
> Sorry, I really don't see how this would make things easier for developers.
>
> > It also draws clear borders between
> > different apps and libs, which is a very good thing for the packagers,
> > users caring about what apps they need etc.
>
> On the contrary, it would make every border fuzzy (see above).

Hi David,

I'm not sure Dominique still suggested splitting everything in its own module. 
At least I didn't suggest it and I have the impression Dominique agreed with 
my opinion.

So, I proposed: let's keep big cvs modules.
But let's organize the basic modules slighty different to decrease 
dependancies. Let's move more or less all libs (and important ioslaves etc.) 
into kdelibs (which might be split into core libs and application level libs)
Let's separate the "real" applications in kdebase (konsole, konqy, kfind) into 
from the desktop applications (kwin, kicker, ksmserver, khotkeys, kxkb) in 
kdebase. Not konqy, konsole, etc. each one in its own module, they all 
together in one "base apps" module.
This would make it possible to install e.g. konqy without installing kwin, 
kicker, ksmserver etc. (I know this can be done now if the packagers package 
it this way, but most of them don't: e.g. suse, slackware, redhat). Still in 
the other direction "kdedesktop" should depend on the base apps (mentioned 
before), so that you have konsole and konqy around if you use the kde 
desktop. The kde apps have become so good that even non-kde users consider 
using kde apps (but not the kde desktop).
Even some more apps could be added to the base apps: kpdf, kghostview, kmix, 
and similar things.
All other modules could stay the same containing more specialized applications 
(kdeedu, kdepim, kdevelop, koffice, kdenetwork). They would stay in big 
modules. But we wouldn't have to juggle apps around in the modules just 
because they link to some library. And these big modules could be released 
together with KDE (as it is now) or independent from KDE (as kdepim is 
planning). 

So where is the problem with this ? (except that it needs work to reorganize 
it) Am I really wrong with this ?

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




More information about the kde-core-devel mailing list