Wanted: theme manager
Matthew Woehlke
mw_triad at users.sourceforge.net
Mon Mar 24 17:53:27 CET 2008
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)
More information about the Panel-devel
mailing list