Color roles, coming this Monday to kdelibs?

[Olaf Schmidt]

Hi Matthew!

[ Matthew Woehlke, Fr., 15. Jun. 2007 ]
> That's what foreground(ActiveText) is...?

Thanks, I missed that. Yes, thank makes sense.

> > and many widget styles currently
> > reuse "selection" as a hover background colour.
>
> Right, hence decoration(HoverColor) :-)

Hm, if decoration(HoverColor) is used for frames, then it is unsuitable as a 
background. But if we have a "tint" function for this, so it is OK.

> It's slightly complicated, I'm thinking the 'best' way is to /mostly/
> preserve the luma of 'color' (in case 'color' and 'tint' differ mainly
> by luma), but from there it's not as simple. Depending on the chroma* of
> 'tint' you may want to leave the hue alone or take only some of the hue
> of 'tint', and you probably want more of a linear blend of the chroma
> based on 'amount'.

For many partially sighted users, it is important that you mostly preserve the 
hue of the 'color' (e.g. a low contrast colour scheme needs to stay low 
contrast, and a high contrast light-on-dark colour scheme needs to stay high 
contrast light-on-dark).

For users with strong colour blindness, it is important that the saturation 
and the hue of the 'tint' are preserved. For them it would be ideal to also 
reflect differences in luma if you generate two different colours, but this 
clashes with the requirements for most other partially sighted users.

But applications should show all information in text- or icon form anyway.
Colour may only be used as an additional visual clue; so I suggest you ensure 
that the luma contrast and the hue are kept and focus on nice results 
for "normal" users otherwise.

> (*recalling that "chroma" == "saturation" unless you're really being picky)

I didn't know about the interesting concept of "chroma" before you forwarded 
me the link, so no, I am not picky.

Olaf