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

Brad Hards bhards at bigpond.net.au
Tue Mar 16 19:55:23 GMT 2004

Hash: SHA1

On Wed, 17 Mar 2004 05:06 am, Alexander Neundorf wrote:
> IMO kstars, kpovmodeller, quanta, kdevelop, amor and other things like this
> are not the "core" of KDE. They are very good applications, but they are
> not the core of a desktop.
> When KDE was started, the basic applications were grouped mainly according
> to their "topic": kdenetwork, kdegraphic, kdemultimedia. Nowadays these
> modules have grown very much and include much more than just basic desktop
> environment applications.
A desktop needs to be complete in application coverage, but not force you to 
take a lot of stuff you don't want. I can see a reasonable kdegraphics 
without kpovmodeller (for example). So it could live somewhere else.

But the focus of the module structure should be "what is a logical arrangement 
for developers (including graphic artists, documenters, translators, coders, 
QA folks - everyone in the process), people who routinely build from CVS 
(generally our testers) and packagers". In about that order of priority.

Right now, we have tools to handle just about everything we need to do with 
the current CVS archive. We need to show that there is some gain to be made 
that justifies changing the way people work. So what will be gained by an 
alternative structure, relative to what can be done right now with the 
correct application of available tools?

The only thing I can see is the ability to promote some of the "outside" 
applications, like scribus (or apollon :) to first-class KDE citizens. Not 
sure how that would work though.

If we just want people to perceive KDE dependencies differently, we probably 
just need to work with the packagers. But what will really change for either 
external or integrated KDE development.

Version: GnuPG v1.2.3 (GNU/Linux)


More information about the kde-core-devel mailing list