overhaul of some kcm appearance

[Aaron J. Seigo]

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

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

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

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

i'd offer:

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

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

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090316/ede5f0c9/attachment.sig>