Refactoring KCM technology

[Cornelius Schumacher]

On Sunday 21 March 2004 20:38, Frans Englich wrote:
>
> Yes, true. But isn't this a little bit too conservative? KDE
> developers will have to update their sources and recompile
> khelpcenter, big deal. Why should we at all hack on KDE when we're
> not allowed to do changes? Why are people into this if they can't
> live with changes? This really is a non issue.

It is not, because there are no good reasons for moving stuff to 
kdelibs. If we would gain something by it, it might be worth the 
effort, but as we don't gain anything besides additional work for 
everybody, we should really refrain from doing it. KDE really needs 
some more stability as development platform, so it would be good if we 
would be more conservative.

> If this is holding 
> back moving khelpcenter we should not do the other moves proposed in
> this thread(or any moves at all, for that matter).

Which would be the best solution, right.

> And packagers use CVS. We should help packagers and make their life
> easier - for their's sake and ours. Besides, there are major
> distributors who ship the CVS modules in "vanilla" state.

KDE already makes packagers life quite easy. Moving stuff around between 
packages is something which is really bad for packagers.

> > No. For keeping interfaces stable in KDE brutal force is the only
> > thing which seems to work ;-)
>
> Agreed :) But I don't see how this move has at all to do with this. I
> mean, it's not like someone will use khelpcenter's private API's
> right?

Sure? But I meant it more the other way around, that if applications are 
part of kdelibs, it's too easy to adapt the libs to special needs of 
the apps. It's very healthy for the interface of a library if it isn't 
changed to easily.

> > No. Take a look at what packers do to our source packages.
>
> So just because they change them means we should not try to make them
> as good as possible? There's perhaps a reason to why they
> fork/change? They change our modules for a reason - because the
> modules does not fit their needs(among other reasons). These moves is
> proposed so KDE modules becomes closer to fit users/distributors
> needs and can be used out of the box.

The modules can be used out of the box. Install kdelibs and kdebase and 
you have the platform you are asking for.

> Aaron's point(AFAICT) and mine too is that kdelibs should contain
> software necessarily to use KDE technologies in order to be able to
> run KDE applications. That may be libraries, service files or
> applications - whatever an application needs to use the KDE
> technologies. Why should kdelibs only be constrained to libraries
> when it's anyway not enough for running a KDE application?

Because libraries are something different than "all what is needed to 
run a KDE application". Libraries are compile-time dependencies, they 
are required to build a KDE application. Running KDE is something 
different. This needs much more stuff. If you require to build all 
applications and other stuff which is needed to run a KDE application 
before you can build a KDE application you are making developing and 
packaging for KDE harder not easier.

> > > > It works fine as it is now, why should we change it?
>
> It does not work fine as it is now. What happens when the use select
> "Help->X Handbook" in an arbitrary KDE application while only having
> kdelibs installed?

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. 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.

-- 
Cornelius Schumacher <schumacher at kde.org>