Solving the colour scheme issues properly

[Matthew Woehlke]

Olaf Schmidt wrote:
> KColorScheme and the new tint function has received a lot of positive feedback 
> from people here at aKademy.

That's nice to know; I hear exactly zero of this. :-)

> People have only been very confused about complicated way to get a coloured 
> background, so we should really add a convenience function for this to 
> KColorScheme and improve documentation.

Ok, I'll propose a patch either today or Monday.

Is KCS::tintedBackground(ForegroundRole) sufficient? The implementation 
would be along the lines of:
   KCU::tint(this->background(), this->foreground(role))
(This signature, the name in particular, would also allow us to change 
our minds later about having individual background roles for each 
foreground role without breaking BC.)

It *might* make sense (but would invalidate the above 'leeway to change 
our minds' comment) to add an overload that takes a non-default base (do 
we need one?), but I'm more hesitant about taking a non-default tint 
(and taking non-default for both is right out), since then I don't see 
why you wouldn't be using KCU::tint directly.

> Yes, please add a convinience functions for
> KCS::foreground() + KCU::tint -> background

Discussed above.

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

> KCS::decoration() + KCU::tint -> focus background
> KCS::decoration() + KCU::tint -> hover background

Since we don't know how the artist will be using the decoration, I'm 
less convinced this makes sense. Plastik, for instance, uses a gradient 
(ok, a 2-pixel gradient) with one end AFAIK equal to the decoration 
color, combined with a very subtle background tint.

Ultimately I think that a: methods used by styles won't look much like 
methods used by applications, and b: we really need something like a 
guessDecoration() that takes the current QPalette and tries to Do The 
Right Thing when applications are using a non-standard palette. For 
instance, if the user has chosen for their hover color to be very 
similar to, or the same as, highlight text, then we return that role 
from the QPalette if the background is different. However there are a 
lot of touchy issues here that I don't think can be resolved in two 
weeks (which is the time we have left for 4.0).

> I have now also tested the tint algorithm.
> [snip]
> With white as base colour, your algorithm returns an invisible yellow tint 
> for "amount" < 0.7. At the same time, the contrast is too small for the tint 
> colours blue and red with "amount" > 0.4. Even worse is the contrast for 
> other base colours:
> [snip]
> As a suggested solution, I experimented with a new algorithm (Tint2) that
> a) returns colours with enough saturation to see the tint, and
> b) always returns colours with enough contrast.

I personally don't think your test is reasonable in cases where the base 
and tint colors don't have enough contrast to begin with; IMO this 
constitutes GIGO behavior. The "typical use case" after all is to feed a 
background and foreground color, in which case this won't happen. (I'm 
also not concerned with the quality of the results when the amount is 
other than the default; since amount == 1.0 is intended to give tint, 
larger amounts are /expected/ to fail the 'sufficient contrast' test.) 
 From an artistic standpoint, I strongly prefer the current behavior 
where amount==0 -> base, and amount==1.0 -> tint, thus giving a 
(decidedly and purposefully non-linear) gradient between base and tint 
over 0.0 - 1.0 for amount.

Anyway, I think there are two questions here; one, what is KCU::tint 
meant to do, and two, what hue should it produce? (In reverse order...)

2. IMO it is more beautiful if red+blue -> purple and blue+yellow -> 
gray, this is what I would expect from an artistic standpoint. Is this 
unacceptable from an a11y standpoint? It doesn't seem to me that it 
would be, but of course you are the expert here :-). (At any rate, I 
think your algorithm needs to be fixed, I don't consider it "ok" for 
blue+white to give red.)

1. It seems to me you are trying to write the 'calculate a sufficiently 
contrasting color' function, which is not what I intended tint() to be, 
and IMO not what it should be. That particular function is more for 
u7y/a11y "only" and not nearly as useful as an artistic function, which 
I meant for tint to be. KCU::tint() is meant to look nice and also to 
produce acceptable results from reasonable inputs, not to be proof 
against *un*reasonable inputs.

At any rate, I would like to do my own review, using your criteria for 
"acceptable results", of the current algorithm under circumstances in 
which I would consider the inputs to be valid. I probably won't get to 
it until Monday however.

[1] http://permalink.gmane.org/gmane.comp.kde.devel.core/43282

-- 
Matthew
"Resistance is futile" -- Borg
"No, resistance is the reciprocal of conductance" -- Dave Korn