Refactoring KCM technology

Leo Savernik l.savernik at
Mon Mar 22 21:18:14 GMT 2004

Hash: SHA1

Am Montag 22 März 2004 17:46 schrieb Frans Englich:
> > KDE already makes packagers life quite easy. Moving stuff around between
> > packages is something which is really bad for packagers.

Indeed. All packagers should have accustomed themselves to the KDE structure 
to build their packages from. Let's save them the work to rewrite their 
scripts, and let's save ours.
> And then I say we shouldn't code because that is cumbersome. Just because
> you find it easy does not mean we should not try to make it even more
> easier. No doubt moving stuff around is bad for packagers and so is also
> breaking BC in KDE4 or changing UIs. But we do it for a reason - for the
> better in the long run.

Better for *what*?
> This move is done once, and bugs the packagers once. For the rest of the
> time it makes life easier, like all other development on KDE.
> It's not a bid deal. KDE 3.3 changelog: "<b>KHelpCenter moved to
> kdelibs</b>"

Yeah certainly. Then, in KDE 4.0 kfoo will be moved, in KDE 4.1 kbar. Once let 
loose, it will never stop.

> > The modules can be used out of the box. Install kdelibs and kdebase and
> > you have the platform you are asking for.
> You are not that stupid. You _know_ why some of us want to move khelpcenter
> to kdelibs. Since the point is irrelevant, why do you bring it up?
> Or do you think it is good KDE applications have a dependency on kdelibs
> AND kdebase? Does it not matter?
Yes. kdelibs+kdebase resemble the least common multiple when referring to KDE. 
It is guaranteed to be available.

> Sorry, I am far from convinced. I think it could be a good idea to see the
> dangers of keeping it in kdebase - it actively hinders the advancement of
> KDE as a platform/technology. The message with keeping khelpcenter in
> kdebase is "If you want to use our technologies you will also have to use
> our desktop". It is not neutral mechanisms, it is policy. When we swear at
> the various companies' customer lock-in methods they are not very far from
> what this is all about.

Customer lock-in? This is KDE. This is *free software*. There's no such thing 
like customer lock-in.

If you mean that kdesktop+kwin should not be contained within kdebase, that's 
a point worth discussing. However, the rest (libs, kio, konsole, konqueror) 
resembles prerequisites, and therefore must be available.

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


More information about the kde-core-devel mailing list