[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: overhaul of some kcm appearance
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2009-03-13 13:28:53
Message-ID: 200903130728.57656.aseigo () kde ! org
[Download RAW message or body]


On Friday 13 March 2009, Oswald Buddenhagen wrote:
> On Thu, Mar 12, 2009 at 04:15:04PM -0600, Aaron J. Seigo wrote:
> > if libplasma can make kwin and kdm and whatever other bits look more
> > coherent, with or without plasma, we'll be a lot closer to the goal of
> > visual coherence and consistency.
>
> that's a red herring, if not worse. you are arguing for coherency by
> plasmification (to whatever degree),

no, i'm arguing for coherency. <-- full stop.

> as if this was the only way to achieve that goal.

of course it isn't the only way. it just happens to be the only way that 
people have actually put any effort into bringing coherency to the workspace 
in the last however many years (far longer than kde4 has been in development).

> that's exactly the "plasma everywhere" way of
> thinking which you agreed is not the way to go.

now you're just twisting my words. (and that's not nice)

i'm being reasonable and agreeable and as such certainly agree that making 
some random kde utility depend on libplasma "just because" wouldn't make 
sense. (btw, i used ksnapshot as an example, since i both work on it and shows 
a preview of the screen, which is relevant in this particular example).

however, using libplasma where it makes sense, and it absolutely makes sense 
in the workspace, is, well, sensible.

so my position is "use it where it makes sense, not where it doesn't." i know 
that's not exactly black-and-white and may require us to all put a bit of 
thought into it because it's not black-and-white, but it's the most reasonable 
answer.

> what's next? link
> kdebase apps to kdevplatform and koffice/guiutils just because they
> happen to have some nice functionality which improves coherency?

if they have some useful functionality that should be shared amongst multiple 
KDE applications then that code should end up in kdelibs and shared as such. 

just as we have always done in kde.

however, if the code doesn't end up in a module that creates a sensible 
dependency chain, then no.

or if the type of coherency is one that isn't actually useful to anyone, then 
probably not either.

neither of those things is the case here.

if you insist on your position, that's fine. we can disagree on this point. 
this patch of Marco's is still going in because it's obviously the correct 
thing to do from the perspective of bringing some coherency to the user 
experience in the workspace components as a whole.

the rest of it is a tempest in a teapot that we can discuss over beer 
sometime.

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


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]