Solving the colour scheme issues properly

[Matthew Woehlke]

Olaf Schmidt wrote:
> [ Matthew Woehlke, Fr., 6. Jul. 2007 ]
>>> KCS::decoration() + KCU::tint -> focus text
>>> KCS::decoration() + KCU::tint -> hover text
>> "hover text" is generally pronounced KCS::ForegroundRole::ActiveText,
>> although it is meant for when only the text changes (i.e. links).
>> Otherwise, given that the text may start out as any role, should we
>> really be changing it?
> 
> Wouldn't it be confusing to have different hover colours? IMHO the user should 
> only configure one colour to be used (in derivatives) by all applications 
> (and by the default style).

Are you talking about hover bg and hover fg being different, or about 
one hover color for each set?

> OK, then I misunderstood the purpose of KColorUtils:tint().
> 
> Most application authors do not want to bother with artwork decisions. They 
> simply want a background that is OK for a11y/u7y, and that integrates well 
> with the general artwork of the desktop. They want one single, error-safe 
> class to handle all their colour scheme needs.

Agreed. I still want to check though if the current KCU::tint isn't up 
to this when used correctly. A KCS method calling into it will insulate 
against the 'proper use' problem, and IMO it's reasonable to assume that 
the inputs are safe (and also if we need do, we can do additional 
sanitizing in KCS).

> Here at aKademy, developers have repeatedly asked me how to get a safe 
> background colour for their application. Sending them both to KCS and KCU 
> (and educating them about proper use of KCU to prevent GIGO) is too 
> complicated.

The previously mentioned, to-be-proposed API will help with this, I 
guess? Note: it would be great if I heard more of this feedback, right 
now I feel a bit cut out of the loop :-).

> KCU obviously addresses a difference audience (style artists, widget authors 
> with artistic aims), and should probably be decoupled from the needs of KCS.
> 
> How about leaving the "tint" function as it is (for artwork) and having a 
> function in KColorScheme that simply returns a new colour (without 
> any "amount" setting)?

I think that's exactly what I'm thinking for KCS::tintedBackground, 
although I would prefer to use KCU::tint in that if it's safe. But this 
implementation will let us change the KCS method also without breaking BC.

(I know you wrote more, I want to think about it a bit longer before 
replying; just so you know I'm not ignoring it :-). I also want to tread 
very, very carefully because we're getting a little far into the 
'guessing what is needed' which is not the best way to build API's. 
People have already been yelling at me for that ;-). I think right now 
we are about at the point where it is better to let the dust settle and 
see what we really need before changing kdelibs in ways that we might 
regret in six months.)

-- 
Mathew
(sorry, .sig file is on the other computer)