overhaul of some kcm appearance

[Lubos Lunak]

On Monday 16 of March 2009 23:11:58 Oswald Buddenhagen wrote:
> On Mon, Mar 16, 2009 at 10:49:21PM +0100, Alexander Neundorf wrote:
> > Or structure kdelibs a bit like kdebase, with a set of "core"
> > libraries (kdecore, kdeui, kio, kfile), and some not so-core stuff,
> > like e.g. katepart, lkhtml, plasma, ftp and http ioslaves, kdoctools,
> > etc. ?
>
> it's not about the distribution to participating developers (which is
> whom our meta-modules concern), but about the libraries themselves.
> most of the "peripheral" libs are fairly small and address exactly one
> issue. this, however, cannot be said about our central libs. they contain
> everything and the kitchen sink. this means that if you want one thing
> (thing being defined as a general theme, not just one class), you get
> 100 others plus their dependencies. this is inacceptable to a developer
> who tries to be truly desktop-agnostic and wants to minimize the number
> of points of failure. ready availability of kde "everywhere" will not
> significantly change this situation, i think.
>
> of course, properly structuring libraries and their dependencies is hard
> work and poses additional challenges to integration (gnome seems to
> have (had?) issues on that front). but it is a price you have to pay to
> reach wider acceptance. even internally, as you see.

 We have just a different approach and I don't think one or another is clearly 
better technically. I mean, I'm really unhappy about the fact that the window 
manager now pulls in a full-blown HTML rendering engine just because the 
Plasma people decided to roll their own look&feel and now others have to 
be adjusted so that Plasma does not stand out like a sore thumb, and in a 
stupid way I'm happy I haven't had the time to do any KDE4 benchmarks in 
ages since I will probably freak the day I finally get to it, but I don't 
think there's a magic solution.

 The Gtk (X11,whatever) approach of shipping a zillion tiny libraries that you 
eventually pull in all anyway is lame in its own ways (like, for example, I 
think they almost caught up with us WRT the .so performance problems 
despite not using C++).

 I can't really comment on libplasma since I don't know what it contains, but 
if it contains stuff that can be useful to generic KDE apps and not just 
Plasma apps[*] but it would have too heavy dependencies for those apps to 
be used outside of the KDE desktop[**], refactoring and moving some stuff 
should be considered.

[*] For a sane definition of "Plasma app" - "an app that links libplasma" 
must be the most lame and useless definition there could be, and if there 
isn't a better one, I guess the move of libplasma to kdelibs missed one 
important detail.

[**] Incidentally, I've been recently thinking more about trying to popularize 
KWin usage outside of KDE. I wonder how most people will view something 
that pulls in 50+MB of libraries though :-/.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz