Refactoring KCM technology

Cornelius Schumacher schumacher at kde.org
Sun Mar 21 01:54:25 GMT 2004


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

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

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

> > - 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. 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
> kde-apps.org 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.

> > It works fine as it is now, why should we change it?
>
> to make it better =)

Have fun ;-)

-- 
Cornelius Schumacher <schumacher at kde.org>




More information about the kde-core-devel mailing list