KDE 4 modules structure (again) (was: structure of kde cvs modules, was Re: libkipi in kdesupport)

Cristian Tibirna tibirna at kde.org
Sun Mar 14 18:07:27 GMT 2004

On Sunday 14 March 2004 07:55, Dominique Devriese wrote:
> Cristian Tibirna writes:
> > IMO, apps should be hosted independently (each one
> > in its module, with their respective docs, web page and
> > internationalization. But I'm far from knowing if this is even
> > feasible.

> I very much second this. 

The discussion degenerated unfortunately towards arguments of technical 
feasability. This wouldn't be wrong in itself, but the actual arguments 
brought forth aren't IMHO of primary importance.

I deliberately left any arguments out in my initial argument. I think stronger 
arguments come from the "sociological" aspects. I thought from the very 
beginning about this (by "very beginning" I mean 1997) but then the goal was 
creating a minimal collection of apps that would provide a fully functional 
desktop. So, having kdelibs, kdebase and kdemultimedia wasn't a problem back 
then. I always thought apps would automatically get inserted in the 
development infrastructure outside the realm of the actual minimal desktop. 
Time proved me wrong.

My main bone with the current arrangement is the perceivedly high barrier of 
entry for new applications in what appears to be a "pantheon" of "official" 
KDE apps. First and foremost, such a "more equal apps" group shouldn't exist. 
Second, we wouldn't need then to witness happenings like the last week's 
switch of kpaint out and kolorpaint in the kdegraphics module.

The best behavior was shown by the koffice apps set, but even then, instead of 
developing an essential minimal framework and then leave the apps to their 
own development rhythm, developers chose to pack them together.

I'm sure you can see the problems of our current way of doing. Apps inside a 
module are easily gaining different levels of 
completeness/functionality/popularity. Dumping many apps together in a CVS 
module creates: a) a mean leveling of the perceived quality of all the apps 
in the module; b) an artificial barrier to the developer that would like to 
start anew some app that would compete with the app in the "official" module.

I'm not sure I managed to illustrate my points, but I don't want to become 
boringly long.

Thanks for listening.

Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org

More information about the kde-core-devel mailing list