Transparent themes without composition

[Marco Martin]

On Saturday 02 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.

if it never will, linux desktop has simply blatantly failed, because it means 
it reached the maximum it can do nd no further evolution is possible, so in 
the next years it will be left behind by operating systems unaffected by those 
silly problems.
but i think that's not the case, it's a very painful transition but is doable, 
and compromises like that just make pointless delays.
it will piss some people off, yes but we must push the limit as hard as we 
can, that's a key point of plasma, otherwise we're stuck in stagnation.
and in the process also things that seems irrelevant like fake transparecies 
yes or not becomes important, because that defines what is the technology we 
want to push

>
> >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.
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel