Solving the colour scheme issues properly

[Olaf Schmidt]

[ Matthew Woehlke, Fr., 6. Jul. 2007 ]
> Ok, I'll propose a patch either today or Monday.

Thanks a lot!

> Is KCS::tintedBackground(ForegroundRole) sufficient?

Yes, this would be enough, and I agree that the flexibility to change 
implementation later is a good thing. See below for a suggestion that goes 
even more in this direction.

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

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

I agree mostly, but the focus/hover colour derivatives for 
foreground/background would mainly be a convenience function for applications 
that implement their own widgets (e.g. hovered text in khtml, and hovered 
background in Kontact).

The Plastik style can stay unchanged, and we can discuss accessibility with 
the Oxygen style authors separately. They might use this function, or 
something else, depending on their own artistic decisions.

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

I agree.

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

Yes, you are right that the mixing between the base colour and my "full tint" 
did not work very well.

I have now changed the PHP page to use the equivalent of
KCU:mix (baseColor, fullyTintedColor) for amount < 0.5
KCU:mix (tintColor, fullyTintedColor) for amount > 0.5

Amount 0.5 is now the fully tinted colour, which is the only thing that I 
really care about, and only in the context of KCS (see below).

It is computed like this (pseudo-code):
    hue_fullyTintedColor = hue_tintColor
    saturation_fullyTintedColor = saturation_tintColor
    if (luma_baseColor < 0.07)
        luma_fullyTintedColor = min (luma_tintColor, 0.07)
    else if (luma_baseColor > 0.65)
        luma_fullyTintedColor = max (tintColor, 0.65)
    else
        luma_fullyTintedColor = luma_baseColor

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

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.

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.

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


The most beautiful API for this would be to extend backgroundRole to include 
all tinted colours (that a tint is used internally is an unimportant 
implementation detail).

Then we would have:

NormalBackground=0
AlternateBackground=1
ActiveBackground=2
LinkBackground=3
VisitedBackground=4
NegativeBackground=5
NeutralBackground=6
PositiveBackground=7
FocusBackground=8
HoverBackground=9

and:

FocusText=8
HoverText=9

I left out InactiveBackground because in the default setting, a grey tint 
would look confusingly similar to already existing colour roles.


In our colour scheme document, the HCI workgroup also suggested to have a way 
for applications that _really_ need more colours (e.g. Konversation, Kopete 
or Kate) to easily generate them, for example:
KCS::background(backgroundRole, QColor)
KCS::foreground(foregroundRole, QColor)

The backgroundRole/foregroundRole would be only used if "strict mode" is set 
in the colour scheme (for colour blind users). If it is unset (default),
a new safe colour is returned.

This function needs an algorithm that can accept really any tint colour, so 
that it is extremely easy for developers to use it. For this purpose, it 
makes most sense to take the hue and saturation from the tint and the luma 
from the base.

For KCU:tint (and not KCS), different requirements might well apply.

Olaf