Wanted: theme manager (was: KDE Opportunities)

[Aaron J. Seigo]

On Wednesday 12 March 2008, Matthew Woehlke wrote:
> > 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 sorry, but i defy you to prove that. if anything we lack an accessibility 
theme.

as for usable, i'm really not sure what you're refering to (unless it's the 
advanced options in krunner?)

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

yes, it uses svg. long live the death of the "theming is only for c++ people" 
idea.

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

i really don't know what more you need. other than a full theme that does 
this. which there already is, on kde-look.org. it's set to appear in 
extragear at some point as well.

> Anyway, I was 
> imagining that plasma would have its own set of colors, that could be

it does if the theme provides one. the Plasma theme can either supply it's own 
colors file (it's KColorScheme compliant, of course; in fact, we use 
KColorScheme internally to process it) or it can leave it out in which case 
we use system colours.

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

if the svg theme provides it's own colours, it's not colour themable. that's 
the definition of it providing it's own colours file. if it doesn't provide 
it's own colours file, then it either can be colourized or is magically 
neutral (i don't think that's actually possible ;) and then we just follow 
the system colours.

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

that's what i keep saying, but colour scheme authors keep proving me wrong ;) 
and then i get b.k.o reports. =)

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

it sounds like it, but it's almost nothing like it. what i'm suggesting is 
allowing the "style" (e.g. widget style) act as a director to the rest of the 
components, so that everything flows from the widget style on down. not 
pixmap themes (unless that's what the widget style is, of course =) and not 
some external, arbitrary mish-mashing via a .desktop file of various 
resources.

done this way the UI could even be pretty.

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

yes, i know that's the opinion out there. i (and the makers of other operating 
systems) disagree. =)

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

no, i'm happy that kde3's wasn't ported. it was a mess. i'm suggesting 
something altogether different.

> > and let's not even talk about cursor themes, sounds, wallpapers ...
>
> ...all of which should be handled by a good theme manager :-).

sure, but these aren't quite as requiring of coherency as 
widgets+windows+desktop+colours. those 4 things should go nicely together and 
be mutually definable through a system of constraints.

the current control panels can remain for the tweakers such you and me, 
perhaps =)

-- 
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 Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080312/0e261471/attachment-0001.pgp