why kdelibs?

[Albert Astals Cid]

A Dijous, 28 d'octubre de 2010, Pau Garcia i Quiles va escriure:
> On Thu, Oct 28, 2010 at 9:22 PM, Milian Wolff <mail at milianw.de> wrote:
> > Pau Garcia i Quiles, 28.10.2010:
> >> On Thu, Oct 28, 2010 at 8:53 PM, Matt Williams <lists at milliams.com> 
wrote:
> >> > Especially with the recent news of Qt breaking apart into smaller
> >> > projects (http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/) I
> >> > think there's a place for a few smaller KDE libraries to fit into the
> >> > picture shown in that blog post (somewhere near "Other Qt solutions").
> >> > While, of course, keeping rocking with our wonderfully integrated
> >> > desktop environment.
> >> 
> >> Agreed.
> >> 
> >> In addition to that, I wonder if all the stuff in kdelibs should
> >> really be in kdelibs.
> >> 
> >> There are a *ton* of classes in kdelibs. Although I have not performed
> >> any checking, I'd say a good number of them are only used by 2 or 3
> >> applications (which is OK by the current policy: you have 2 users for
> >> your class, it's in for kdelibs). Maybe a class should have at least
> >> 10 or 15 users to get in kdelibs, and specialized classes, with a
> >> narrow scope, should be in other libraries.
> > 
> > I disagree. This does not solve the problem, which is: It's not modular
> > enough. I mean if it would be in kdebase, then one would require that.
> > Look at e.g. KDevelop requiring kdebase since noone is moving the "pick
> > process" widget from afaik ksysguard into kdelibs even though kdevelop,
> > scintilla, ksysguard and I think others as well are using that.
> > 
> > It's not like there is a "ksysguard" library. You link against kdebase
> > which again is a big bunch of stuff.
> 
> That's exactly what I'm proposing: instead of requiring kdebase, have
> a ksysguard library, even if atm it only contains the 'pick process'
> widget.

I see 5 libraries inside kdebase/workspace/libs/ksysguard

Albert