Transparent themes without composition

[David Nolden]

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

>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
>* people using compositing asking for it
Then don't deny it from them, it's a nice feature for everyone
>* 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?

>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. You have learnt 
from the mistakes done in kicker, and you don't have to repeat them. But still 
you cannot deny some essential features, eg. a nice looking Desktop, from such 
a large number of people. I agree that this is very close to the border, but 
you can also say "until here and no step further".

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

>> With the color thing implemented, adding support for a pattern is only a
>> question of a few lines, and I cannot see a rational reason behind not
>> allowing it when allowing the color.
>
>because this will end up requiring configuration UI, is something that
> belongs in the theme itself and is YACP (yet another code path)
Right now I would even be happy if it did not have any configuration UI at 
all.