From kde-core-devel  Fri Mar 13 13:28:53 2009
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Fri, 13 Mar 2009 13:28:53 +0000
To: kde-core-devel
Subject: Re: overhaul of some kcm appearance
Message-Id: <200903130728.57656.aseigo () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=123695098922634
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart34364611.ZQidgmYdiV"

--nextPart34364611.ZQidgmYdiV
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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=20
people have actually put any effort into bringing coherency to the workspac=
e=20
in the last however many years (far longer than kde4 has been in developmen=
t).

> 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=
=20
some random kde utility depend on libplasma "just because" wouldn't make=20
sense. (btw, i used ksnapshot as an example, since i both work on it and sh=
ows=20
a preview of the screen, which is relevant in this particular example).

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

so my position is "use it where it makes sense, not where it doesn't." i kn=
ow=20
that's not exactly black-and-white and may require us to all put a bit of=20
thought into it because it's not black-and-white, but it's the most reasona=
ble=20
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 multip=
le=20
KDE applications then that code should end up in kdelibs and shared as such=
=2E=20

just as we have always done in kde.

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

or if the type of coherency is one that isn't actually useful to anyone, th=
en=20
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.=
=20
this patch of Marco's is still going in because it's obviously the correct=
=20
thing to do from the perspective of bringing some coherency to the user=20
experience in the workspace components as a whole.

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

=2D-=20
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


--nextPart34364611.ZQidgmYdiV
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkm6X5kACgkQ1rcusafx20Pl9QCfUhs65ZtvV06EFNYvWZO+tN30
TEAAnjdsIjb3m31VodmBebwMR7fPNThz
=i7pE
-----END PGP SIGNATURE-----

--nextPart34364611.ZQidgmYdiV--