Transparent themes without composition

[Aaron J. Seigo]

On Friday 01 May 2009, David Nolden wrote:
> >On Friday 01 May 2009, David Nolden wrote:
> >> This already looks quite nice. But since many plasma themes have a
> >> glassy look, they highly profit from something more shining through
> >> them, since that's the only way they can retain that look. Transparency
> >> is not
> >
> >and if you want that, use compositing.
>
> Composition is simply not an option. And for some users, it never will.

that doesn't mean we need to, or should, try and fill in that gap.

> >it's not a must-have feature and is
> >exactly the kind of "well, we'll just cheat a bit when it's not
> > compositing" feature i am so not favor of. it leads to:
> >
> >* more configuration UI
>
> Useful configuration

every configuration is useful to someone. that is not a justification, and it 
certainly doesn't help the people who have no need for it but who have to put 
with having to figure out the resulting configuration systems.

this is not kde3.

this is not a dog's breakfast of shitty dialogs with dozens and dozens of 
configuration widgets in them each.

> >* people using compositing asking for it
>
> Then don't deny it from them, it's a nice feature for everyone

right, which means the configuration UI braindamage extends everywhere, we end 
up with "theming" now being a chimera of multiple code paths spread across 
libplasma and/or the shells ... no.

> >* more difficulty in q/a as we have more variables to test for and code
> > around
> >the idea really is to degrade gracefully *from* compositing to non-
> >compositing, not to add features to non-compositing that aren't available
> > in the compositing case.
> >
> >non-composited desktop should look good and work well, but they are not
> > the primary target. they are a supported secondary target.
>
> Plasma is an essential part of KDE. Now you define that non-composition
> users are not the primary target of KDE? Why is about 50% of all users not
> the primary target?

* their computers are not the primary target; they can always get a different 
computer and enjoy it. this is not about the *user* but about their 
*hardware*, so it's not a bias against a certain group of humans.

* as time goes on more and more of the systems people have do compositing very 
nicely. many do already and in the not so distant future it will account for 
the overwhelming majority of systems in use.

* i'm not willing to commit to supporting what amounts to work arounds and/or 
additional code paths (and all the complexity and half-proper features they 
bring), given the above

(btw, by "half-proper" i mean things like "doesn't actually fully work or look 
correct"; that's not a "code correctness" issue but a "doesn't look like a 
joke" issue.) 

> >because the next step along this path is "why don't we show window
> > thumbnails using screen grabs in the tooltips when there is no
> > compositing" and on and on. result? a bloated, horrible mess that has
> > lots of sorta-kinda working features in the non-compositing case.
>
> As an intelligent human, you should be able to compromise.

i am quite capable of compromise. i also know when not to. just because one 
can compromise does not mean it is what one does in every single situation.

> You have learnt
> from the mistakes done in kicker, and you don't have to repeat them. But

well, you're kind of asking me to.

> still you cannot deny some essential features, eg. a nice looking Desktop,

the desktop looks nice.

> from such a large number of people.

i completely reject that it's a significant %, esp in relation to the % of 
people it would end up affecting negatively due to configuration UI additions 
and complexity of the code base. it's a struggle to keep it as uncomplex as 
possible but no more so (in other words "as complex as it absolutely needs to 
be")

> I agree that this is very close to the
> border, but you can also say "until here and no step further".

thank you for recognizing that. and in case you haven't noticed by now, i've 
been saying that. it's not where you want the line to be drawn, but that's 
just how it goes sometimes.

> >the colour does not belong in the config file. it should come from the
> > theme itself, allowing it to track the desktop colour scheme if that's
> > how the theme is set up. this could be overridden by the active wallpaper
> > for that screen/desktop, perhaps, so that wallpapers can say "here's a
> > good matching colour".
>
> The color needs to find its way from the desktop shell into krunner, kwin,
> etc., so how should that happen without a configuration file?

let me rephrase then: the colour does not belong in the plasma-desktop config 
file as some part of the configuration of that application. it belongs with 
the theming support and should have zero user interaction (as in "if the user 
changes it, it will likely be overwritten")

-- 
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: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090501/856224ea/attachment.sig