Wanted: theme manager

[Matthew Woehlke]

Aaron J. Seigo wrote:
> On Friday 21 March 2008, Matthew Woehlke wrote:
>> Incidentally, I tried "heron"... really bad flickering :-(.
> 
> during the update? or forever? or?

Not forever. Let's see, the digital clock (at least in the panel) likes 
to turn into garbage certain seconds (it tends to alternate between 
garbage and almost-right but with garbage for the last digit, with some 
periods of normality), and occasionally (seems to happen most when the 
panel starts to get full) the task list disappears or turns into 
garbage; mousing over it usually causes very bad artifacts.

This is all with the *default* theme... it seemed worse with heron but I 
may have just imagined that.

As I typed this, I could see the task item for this window; everything 
else is black. Until I mouse over, at which point I get Flicker and 
Artifact City; then I got two OK items, one corrupt, two more OK 
(including this window), and one missing item. And mousing over some 
more, I got it to look OK.

>> Anyway, what is this 'follows the system colors' theme I hear about? I
>> don't seem to have found it yet. What's a theme that supposedly does this??
> 
> Aya

Well, it doesn't seem to accomplish this very well. The background color 
just looks gray, where it should be bluish and darker. The text color 
seems right, if that means much (that doesn't seem to come from the 
svg's at all).

This makes me wonder how coloring is done... the oxygen cursors do it by 
having 'magic color values' that are substituted for system colors prior 
to rendering. I get the impression that plasma applies a 'colorize' filter?

On a somewhat related note, how would the plasma devs feel about a "use 
widget style" mode for plasma, as an alternative to using an svg theme? 
The idea would be for something that integrates with whatever widget 
style the user picks, rather than having to create themes to integrate 
with every style.

>>> i can't find them atm, but will be sure to do so in the future.
>>> essentially, all of our dark colour schemes seem to give people problems
>>> when painting dark() text on a base() background.
>> Ahh... why is this being done? 'Dark' really isn't meant as a text role
>> (it's meant to for "dark" edges of 3d elements), especially when there
>> are eight "actual" text roles to choose from. This feels like a case
>> where you rather want to either use 'Inactive' or paint the normal text
>> color at 50% opacity.
> 
> the text is not inactive, however, and i'm concerned that painting it as such 
> will send incorrect visual cues and look poorly with yet other colour themes. 

If it does, you can yell at the color scheme author :-). (Are we talking 
about the same inactive? I meant KCS::InactiveText, i.e. the color role 
meant for "comments, supplemental information, etc". I tend to design 
color schemes such that Inactive is close to '50% Normal/Background'.)

> 50% opacity might work ... 
> 
> but honestly, i was just plain surprised that palettes aren't treated more 
> semantically. in any case, the docu then need to adjustment (which would 
> probably screw over others).

 From KCS::ShadeRole:

"Color shades are used to draw "3d" elements, such as frames and bevels. 
They are neither foreground nor background colors. Text should not be 
painted over a shade, and shades *should not be used to draw text*." 
(emphasis added)

So the doc already says "don't do this". At least, /my/ doc does ;-). 
Only designated text roles are suitable for drawing text, and then only 
on designated background roles. Anything else risks a11y problems.

> e.g., BrightText is documented as: "A text color that is very different from 
> WindowText, and contrasts well with e.g. Dark. Typically used for text that 
> needs to be drawn where Text or WindowText would give poor contrast, such as 
> on pressed push buttons. Note that text colors can be used for things other 
> than just words; text colors are usually used for text, but it's quite common 
> to use the text color roles for lines, icons, etc."

BrightText may not be handled correctly... honestly, I'd never head of 
it until very recently (meaning, maybe last week, but certainly after 
4.0 was released).

> doesn't sound like the "dark edges of a 3d element" to me.
> 
> and Dark itself is labelled simply: "Darker than Button"

Sorry, but I think you are confused. Text roles may be used for non-text 
things, yes. The converse is not true; non-text roles are not 
necessarily suitable for text. Dark is not a text role.

> i still contend that our palette definitions in Qt are very circumspect.

That may be :-).

I don't think BrightText is even set. Again, I wasn't even aware of it 
until recently. (I'm also unconvinced it should even exist, as its 
description implies a swapping of foreground and background roles, which 
is a major no-no for accessibility.)

> what i'm suggesting is letting styles themselves hint what colour schemes work 
> well with them, for instance. so you don't have to rely on someone else 
> putting together an ad hoc collection (and hoping that the "right set" is put 
> together), but that conversely you aren't confronted with lots of useless 
> options (e.g. colour schemes that simply Don't Work(tm) with a given theme, 
> or non-Oxygen widget styles for the Oxygen window decoration)

Hmm... ok, I guess I see what you're thinking. I'm not really 
disagreeing with the idea, just that my own belief is it shouldn't be 
necessary.


-- 
Matthew
Save soybeans! Avoid TOFU! (http://en.wikipedia.org/wiki/Posting_style)