Refactoring KCM technology

Frans Englich frans.englich at
Sun Mar 21 19:38:48 GMT 2004

On Sunday 21 March 2004 02:54, Cornelius Schumacher wrote:
> On Sunday 21 March 2004 01:01, Aaron J. Seigo wrote:
> > On March 20, 2004 06:36, Cornelius Schumacher wrote:
> > > On Saturday 20 March 2004 13:12, Olivier Goffart wrote:
> > > > Le Samedi 20 Mars 2004 10:46, Cornelius Schumacher a écrit :
> > > > > Just for the record: I'm against moving applications to kdelibs
> > > > > and as maintainer of khelpcenter I would reject a request to
> > > > > move it.
> > > >
> > > > Why?
> > >
> > > - kdelibs is big enough
> >
> > this isn't new code, though. it's taken out of kdebase, so it's
> > pretty much a zero sum game.
> Adding stuff to kdelibs is a zero sum game? That has to be some kind of
> new mathematics ;-)

"zero sum" involving kdelibs and kdebase, +khelpcenter, -khelpcenter. Yes, 
kdelibs becomes bigger but it's not bloating. We shall absolutely not be 
ignorant to saving disc space but it should not constrain us like this. If 
people need to save a 10kb they shouldn't be running a graphical environment.

> > > - moving stuff around is additional work for everybody
> >
> > "just" for the CVS admins, not that i wish further work upon their
> > shoulders. if you have outstanding changes then you need to do a diff
> > and patch locally, but again this is a minor thing.
> Is recognizing a new source code structure and recompiling kdelibs and
> kdebase really a minor thing? This affects all developers using kdelibs
> and kdebase, so you have a huge multiplication factor.

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

> > weighed against
> > the benefits which affect the users (and thereby the developers) of
> > 3rd party software.
> Once again, users use packages, this has nothing to do with KDE CVS
> modules.

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.

> And for the benefits, up to now some people came up with some
> theoretical benefits, but that's completely irrelevant. You have to
> come up with serious facts about practical benefits, otherwise all
> arguments are moot.
> > > - separation between libraries and applications using these
> > > libraries helps in having clear interfaces
> >
> > i would agree with this, however in these special case scenarios i
> > think we can exercise a modicum of self-discipline, no?
> 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?

> > > - application development can happen without the need to update and
> > > compile libraries
> >
> > this wouldn't change from the current situation. or do you build all
> > of kdebase everytime you make a change to khelpcenter?
> Not necessarily, but I certainly don't build kdelibs, which would be
> required if khelpcenter would be part of kdelibs.
> > > We are talking about CVS modules not packages. The modules are only
> > > relevant for development and source code releases. What packagers
> > > do with them is a completely different story which should be
> > > discussed elsewhere.
> >
> > developers count too =)
> Yes, that's my point.
> > and until we officially support binary
> > packages, we ought to take responsibility for the utility of our
> > source packages IMHO
> 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.

> If we would 
> take responsibility for this we would do binary packages, but we don't
> (for very good reasons).
> > > > kdelibs alone should be enough to run mosts of kde application by
> > > > an user which does not use the kde desktop.
> > >
> > > Who says that? What is enough to run a KDE application depends on
> > > so many different aspects that there certainly is no simple answer
> > > like yours above.
> >
> > the only exception to this that i can see are apps that rely on
> > kioslaves such as smtp, pop3, etc... take a browse through
> > and the vast majority of apps there would do just fine
> > with kdelibs if the help center, dr konqi and some kcm stuff were in
> > kdelibs.
> That's debatable. See my previous mail.
> > i think the name "kdelibs" is actually hanging us up somewhat, since
> > what we're talking about isn't "libs" anymore as much as it is
> > "platform".
> No, kdelibs is libs, nothing else. platform is kdebase. That has alway
> been the case and it works well.

(There seem to be some confusion around the platform word, I avoid it)

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 

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

I haven't heard one convincing word for not moving khelpcenter, I am open for 
further (re)explanations, of course. BTW, is there anyone besides Cornelius 
who objects? (and why?)

I will ask sysadmin to move the ones asked for in this thread, except 
khelpcenter and kdesu(which apparently already is moved).



More information about the kde-core-devel mailing list