Refactoring KCM technology

[Frans Englich]

On Monday 22 March 2004 06:48, Cornelius Schumacher wrote:
> On Sunday 21 March 2004 20:38, Frans Englich wrote:
<snip>
> > 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.

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.

I find the argument pointless because it doesn't say why moving khelpcenter in 
the big perspective is bad but promotes an encumbersing aspect as a /reason/ 
to why it not should be done. That is like if I would say "please do not add 
configuration options, it makes debugging harder" or "No more features 
please, it means more bug reports".
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>"

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

That is what you think. Personally I don't think so. I find it just as easy to 
commit in kdeutils/kcalc as in kdelibs/khelpcenter. Why does it become 
easier? Because you don't have to "cd" as far? Aren't we pretty good at 
keeping an eye what goes into the libraries in kdelibs?
Furthemore, this khelpcenter, not a bunch of huge alpha apps from kdenonbeta.

> It's very healthy for the interface of a library if it isn't 
> changed to easily.

(Irrelevant. We all agree on that APIs shouldn't change. We discuss whether 
moving khelpcenter affects that aspect.)

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

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?

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

By making a distinction between run and compile time dependencies on the 
package level, people can't have help in their applications or must install 
kdebase. And we do this distinction so the compile machine chews in kdebase 
rather than in kdelibs? Is it really a big deal? Doesn't David's suggestion  
for an install-libs target count?

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

Ah, nice. "Since application X has so many bugs it's not worth fixing one". We 
take small steps OK? Moving khelpcenter solves the help problem and then the 
users have one problem less. Next time we perhaps have a solution to some of 
the other problem you described(which of course is just as serious).


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.


				Frans