On Monday 30 March 2009, David Nolden wrote: > Just by the way I think we need to find a way to make composition-centric > themes also look good without composition, because it seems like > theme-designers just don't care about that case, and it's also quite a > burden to them. They should just supply masks for non-composition, and that > should be it.
we don't actually need masks for most of these things. the outer border of the painted panel areas is good enough usually, and we even have a method to grab those already in plasma. > either a user-configurable non-black solid color, the wallpaper, or another > generic theme background pattern could be used as background, instead of > black. "the wallpaper" doesn't actually have much meaning in plasma. there's "the wallpaper, if any, of the current Containment associated with the current DesktopView that happens to have the same screen() value as the other object, such as a PanelView". so that's probably not what we want. user configurable seems overkill. we already have the colour scheme associated with each theme. we could pick, for instance, the window background colour from that color scheme and use that as the PanelView wash. that would at least get rid of the black. and for themes that adapt themselves to the user's colour scheme, such as Aya, that colour would actually be user configurable. that's actually a patch set that would be an improvement over the current non- compositing situation. :) > I think it's good that KDE > pushes the technology, but I don't like that it happens by leaving users > behind. fake translucent panels is not leaving anyone behind, nor does it make anything "not work". people continue to use plasma and it looks quite pretty without compositing. in fact, i'm running plasma without compositing right now, as i have been since the last Intel driver update (a month or two ago now?) where they completely botched performance. i'm quite happy with the look and feel of plasma even without compositing. the fake translucency is a trivial feature in terms of user benefit but comes with a high cost to the code base. so the cost/benefit just doesn't work out. and that's simply the fact of the matter. (btw, i'm one of the people primarily responsible for the fake translucency in kicker ... zack is the other.. both of us think it's a bad idea to repeat it in plasma. maybe that says something. :) -- 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
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
