overhaul of some kcm appearance
l.lunak at suse.cz
Tue Mar 17 15:19:37 GMT 2009
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
[**] 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 :-/.
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
More information about the kde-core-devel