Wanted: theme manager (was: KDE Opportunities)

[Matthew Woehlke]

Aaron J. Seigo wrote:
> (no, i'm not going to cross post to three lists =)

Well, u7y should certainly be dropped ;-). Bleh, now I'm subscribed to 
panel-devel :-/. (Which means people can stop CC'ing me now; thanks, 
though :-).) Though maybe this should be pointed back at kde-devel, 
given where it's gone.

> On Wednesday 12 March 2008, Matthew Woehlke wrote:
>> I'm pretty sure you're not the first to complain about plasma's coloring
>> and how it's out-of-place with the rest of the desktop. What probably 
>> needs to happen (assuming the colors can be changed; if not, this needs
>> to be a major priority!) 
> 
> well, let's try and keep some perspective on the problem.

Perspective: it's neither Usable nor Accessible. I'm the u7y/a11y nzai, 
remember? ;-)

(That said, when I wrote that I was forgetting plasma uses svg - er, it 
*does* use svg, right? - and so was thinking that the code changes would 
be simpler than what I am now guessing they would be. So...)

>> is integration with the color kcm, the same way 
>> WM colors tag along despite being not part of the application (i.e.
>> QPalette) palette.
>>
>> As the maintainer of the color kcm, that probably means I'll be doing
>> some of the needed coding. What's been done already on the plasma side?
> 
> there are two things:
> 
> a) svg themes
> b) optional colourization of svg's designed for that
> c) svg theme specific kcolorscheme files
> 
> (b) might be able to be done better: right now it does post-rendering 
> colouraization of the resulting bitmap. it would probably be nicer to do 
> replacements in the svg data itself, but .. yeah .. this works for now.
> 
> and yes, (b) responds to desktop colour scheme changes.
> no the default theme is not colourizable. it might be if we either replaced it 
> with something else or (b) were improved.

Hmm. Ok, so I guess that's what should be worked on, then? Anyway, I was 
imagining that plasma would have its own set of colors, that could be 
part of the color scheme but not directly tied to QPalette colors (i.e. 
so you could choose to make plasma different colors, but still be able 
to customize it without inkscape).

> personally, i think it's a real shame that we have a multiple theming and 
> colouring systems and then try and sync them all together. i think it's 
> really suboptimal to have no conversation between themes and colour schemes, 
> for instance. having them as two completely separate system and expecting 
> them to just work together ignores some basic artwork facts, such as "not all 
> possible themes work nicely with all possible colour schemes". this is not 
> because the theme is 'obviously buggy' but simply because not all gradients, 
> not all shapes and not all combinations of rendering possibilities will work 
> with the same stock palette colours equally well.

I think I would say that's something of a flaw in panel, albeit one that 
would be resolved by a solid solution to (b), above. (c) isn't 
necessarily bad (I'd prefer themes for the color schemes, but I'm 
biased); I have one mostly-done wallpaper and want to do 2/3/more? 
others based on color schemes. And of course I do schemes from 
wallpapers quite often (e.g. Wonton Soup).

> this is compounded by the fact that our palettes are treated as if they are 
> both semantic ("base") and literal ("dark") making it pretty well impossible 
> to consistently use the palette without working around the fact that "dark" 
> actually contrasts with "base" but only some of the time (e.g. often not 
> with "dark" colour schemes).

Um... "dark" should *always* contrast with base (ok, not so much for 
really dark schemes above the invert threshold, but...) though it is not 
always literally darker than base. Anyway, that's all based on the 
semantics of 'use these colors for 3D elements', which IMO is pretty 
well entrenched despite that those colors in fact are allowed to have no 
resemblance to the base color. (Well, ok, we don't really allow this, 
although Qt does.)

> in fact, i'd go so far as to suggest that the style kcm ought to take care of 
> general colour scheme setting and the colour scheme kcm be used by those who 
> would like to tweak said schemes or set an "untested" pairing of scheme and 
> style.

Well, that just sounds like a theme manager :-). Didn't we have that in 
KDE3? ;-)

> and yes, there are styles which can use any colour scheme, and that wouldn't 
> pose a problem with this system.

As far as widget styles, I consider it a bug any time a style doesn't 
work with any reasonable color scheme ;-). (And yes, Oxygen last I 
checked had a number of such bugs...)

> imho it really comes down to us exposing all the implementation details to the 
> user (widget styles are a type of C++ plugin, colorschemes are stored in a 
> separate file, window manager styles are another type of C++ plugin and 
> desktop themes are a pack of svgs... so go to four different places, please!)

Yes, you want a theme manager. I take it this rant means that KDE3's 
wasn't ported? (I never looked, as I'm not big on themes, tending rather 
to create my own...)

> and let's not even talk about cursor themes, sounds, wallpapers ...

...all of which should be handled by a good theme manager :-).

-- 
Matthew
Hey! Where's the witty punchline?
(with apologies to Hostess)