overhaul of some kcm appearance
Aaron J. Seigo
aseigo at kde.org
Mon Mar 16 23:24:42 GMT 2009
On Monday 16 March 2009, Oswald Buddenhagen wrote:
> On Mon, Mar 16, 2009 at 12:09:15PM -0600, Aaron J. Seigo wrote:
> > On Saturday 14 March 2009, Oswald Buddenhagen wrote:
> > > because as is, from a random non-plasma application's perspective, the
> > > lib is more or less "librandomstuff" with very little useful features
> > a "plasma application" is any app that uses libplasma. so yes, if you
> > don't have a need for the things in libplasma, then it's not useful to
> > you. but that's a tautology, isn't it?
> nice way to twist things around.
> i thought a "plasma application" would be something remotely
> plasma-related, from a user perspective.
that would be incorrect, and i see now where we are having a linguistic issue.
to the plasma team, a "plasma application" is an app that uses libplasma,
which may or may not be related to the desktop shell.
this was not how things started, but as we worked it became apparent (to
others outside of pasma first, actually!) that the challenges we faced and
were addressing were common to other applications too. so we split out
libplasma and things like the plasma desktop shell (we even renamed plasma to
plasma-desktop recently to make this more clear)
the user may not even be aware that an application uses plasma at all. that's
really besides the point when it comes to libplasma, which is just there to
provide means to write "stuff on canvas" apps easier and more coherent.
when it comes to the desktop shell, which is mostly made up of apps that
utilize plasma in either a major or minor way, it does matter that the user
can tell but that's from a user experience perspective not a "what libraries
does it use" perspective.
> > apps that don't have a gui won't find anything useful in libkdeui. same
> > thing.
> this analogy simply doesn't hold. you'll find hardly any kde gui app that
> does not use a whole lot from kdeui.
erm. as i said ... if you have an app that *does not* have a gui, you won't
fin anything useful in libkdeui. we have a lot of console-only apps in kde
now, and so we now have a gui-less libkdecore specifically for those kinds of
and yes, if you do have a kde gui you probably use quite a bit from libkdeui.
libkdeui itself hold a whole bunch of different things: xmlgui, font handling,
icons, jobs, widgets, window system stuff, etc, etc...
similarly for libkdecore. calendars and config and what not.
libplasma is all about "widgets on canvas type apps"
> decides to use. this simply isn't the case with libplasma when it is
> used outside the original target context. that's because libplasma is
> not a general-purpose library assembled from many sources, but a
> collection of tools developed specifically for the needs of plasma.
the only thing in libplasma that could be broken out cleanly is the runner
things. we even talked about doing that, but decided it hardly made sense
since it's so few classes and the apps that would use that lib would also tend
to want the other things in libplasma. other than the runners, everything
actually does fit very tightly together.
in that sense, libplasma is *much* more focused than libkdeui or libkdecore or
so unless you can come up with concrete examples otherwise to back up your
concerns, i'd suggest you're talking about something that is well out of your
> > what i'm wondering is what, exactly, you're trying to achieve with your
> > comments here? if you could help me understand what you're trying to
> > achieve, then maybe we can find some common ground in that direction.
> > otherwise this is a waste of our time.
> i'm expecting at least an understanding of the problem on your side, and
> broader attention to the issue - with the slight hope that the mistake
> will not be repeated.
i'm not sure what the problem is. so far you've made a number of false
assertions mixed with vague concern. to appreciate "the problem" you will
first need to communicate what it is.
> as a short-term improvement one might consider refactoring classes from
> libplasma into other libraries and make the plasma libs thin delegates.
> but that's obviously ugly.
other than the runner classes, along which lines would you split things out?
> have you ever wondered why kde is an island beyond those apps which go
> full monty, while gnome core technologies are more or less silently
> penetrating not only the desktop (including kde), but the entire free
> software market?
* an allergy to anything that isn't C
* greater concern about distributions than application developers
* a total lack of pragmatism on the gtk+ people's part that prevents them for
purely ideological reasons from using anything they haven't made
* better political working with the distributions
* and finally, people who work on lower layer things like networkmanager etc
while kde remains focused a bit too much on the higher layers of things which
then naturally biases the lower layers towards things written by "gtk+ people"
and yes, before kde4 we had messy libraries with no internal structure. our
libraries are still "big", though not insanely so, but libkecore and libkeui
are better structured now.
> i mean, apart from the obvious "it's c++"? yes, it's
> badly structured monster libraries with oodles of dependencies. almost
honestly, it would be nice if that were our biggest challenge.
> *every* c++ (and even qt) developer to whom i suggest to use kde
> libraries comes up with this argument.
i suppose if everyone says it, it must be true.
> just as a random data point, kinda ironically we (trolls) are right now
> facing the same situation with some random nokia-internal potential user
if some random group of people say something, it doesn't mean it's true. it
could simply be their perception, what they were told to think by others or a
cunning argument crafted by someone who'd like to stunt the growth of qt/kde
for personal/political reasons.
anyways .. best of luck with the random nokia group. hopefully you find the
right people to talk with them and who can craft a favorable, workable
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel