Color roles, coming this Monday to kdelibs?

[Matthew Woehlke]

Olaf Schmidt wrote:
> Applications have a need for a "hover" foreground colour (e.g. default setting 
> for hovered links in khtml),

That's what foreground(ActiveText) is...?

> and many widget styles currently 
> reuse "selection" as a hover background colour.

Right, hence decoration(HoverColor) :-)

> This was why we suggested a pair of foreground/background colour for both 
> hover and focus. I have no objection to splitting hover and focus, but 
> merging foreground and background into one "decoration" does not meet the 
> requirements.

Basically, the plan is still to generate background colors from 
foreground colors. To answer the question you asked in private e-mail, 
yes I have an idea for this, although I haven't written the API yet. It 
will be something like:
tint(QColor color, QColor tint, qreal amount)

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'. Anyway this is all BC so we can continue to tweak it 
as we discover corner cases, but the main point is that, yes, there will 
be a convenient helper to get a background color from a "safe" 
background and a foreground color.

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

-- 
Matthew
"I can hear you / just barely hear you / I can just barely hear you"
   -- "I Can Hear You", by They Might Be Giants