plasma, panels, colours

[Aaron J. Seigo]

On Friday 07 November 2008, Marco Martin wrote:
> On Friday 07 November 2008, Aaron J. Seigo wrote:
> > (and ok, the choice of colour in the panel there isn't great, but you get
> > the idea)
>
> hmm, dunno, i feel that a light panel with just some black elements really
> tends to scream hey look at me, look at me! and the panel would be a total
> alen compared todesktop widgets

> i think the icons in the panel are kinda enough to give color and exit from
> black on black pattern..

it's not about having a requisite amount of colours from the rainbow, i just 
don't want a morbid black-on-black that also happens to make it ore difficult to 
see, for instance, which is the active window.

the tasks widget, as it is right now with black-on-black, makes it really hard 
to see which is the active window. why? lack of contrast between foreground 
and background.

in a well lit room, it's really, really quite bad. at night in a dark room i 
can see it a bit better.

so we end up with a muddy interface that says either "i'm wicked cool, just 
not in a practical way" or "hey look, i'm darkness and death" (depend on how 
you take it)

> perhaps it's possible to keep it rather in style but not sure (maybe
> similar to the active task button, but with a raised look insted of sunken)
> and kinda agree with riccardo, with a light background maybe could look
> better with maximized windows, dark with not maximized ones

so we screw people who use their whole screen, and continue to ignore that 
black-on-black reduces contrast liiting usabilty and does indeed step over the 
border from elegant and into depressing. fascinating.

> > it's really a lot more appealing with a non-black background. it could
> > still even be a dark colour, but i really don't know how many distros are
> > going to keep with the default theme when the default is, well, rather
> > bleak.
> >
> > i was hoping of putting this off until 4.3, but i'm increasingly thinking
> > that waiting is not only unnecessary but also problematic.
>
> yeah, as you said would impact how theme class work, at least probably, so
> let's do it now if we do it.
> so we basically need a dfferent set of colors depending were we are
> isn't possible to add new custom roles to kcolorscheme, right?

the problem is that kcolorscheme is not designed for this at all. going 
through the enums and the foreground/background/etc splits .. it's not at all 
how we line things up in plasma, since the foreground can very depending on 
whether the applet uses the standard widget background, sits on the desktop or 
in a panel area.

> so besides window, button tooltip etc we would have a panel group...

and for widgets that use something other than StandardBackground?

> or even a more silly idea :)
> put in the panel background svg some elements like hint-text-color hint-
> background-color of the proper colors.
> to fetch it unfortunately should have to be rendered the element to an
> image and sampled (even just a single pixel) maybe
> Theme::colorFromImage(path, elementId) would be a thing a bit heavy weight
> but done just once (maybe even cached)

this is an implementation detail, it doesn't inform us on how the API that 
faces the applet writer should be made, really.

and colorFromImage there would require applet writers to know what the 
background image is, something we've successfully kept away from them.

i'm beginning to lean towards an Applet::color(Plasma::ColorRole, <some other 
param(s)?>) API. that limits the additional classes, can encapsulate whatever 
the implementation is and can use information about the current state of the 
applet (e.g. what background it is using) to choose what color value to 
return.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20081107/6657cb1b/attachment.sig