[RFC] Color usability time...

[Matthew Woehlke]

Now that there is color blending in kdelibs, I would like to get going 
on the more complicated stuff ASAP. Here is a list of things I think are 
needed. Comments encouraged :-). Please note that the primary objective 
is to hash out what we need, and most importantly what the API's will 
look like, so that they can be implemented in at least skeletal form 
before the cutoff in two weeks.

== HSL and HSY
In order to most closely conform to human perception of color, we really 
should be doing operations in HSY. Trying to work in HSV is 
theoretically "do-able" with the help of qGray, but IMO the amount of 
work required to 'guess' how much to darken/lighten a color doesn't 
justify /not/ providing an HSY implementation. Said implementation will 
be lightweight and private. Consideration should be given to moving it 
over to KoColor when that becomes available.

Usage:
There is currently fromHsl code in khtml that will be moved. Also we 
should consider adding at least hsl to the color picker for use on 
Windows (the Windows default color picker uses HSL).

Questions:
Should we make fromHsl public? (khtml will use it, but that's internal 
to kdelibs) Should we expose toHsl at all? What about *Hsy? Should we 
have only *Hsy with a parameter to specify the coefficients (including 
'equal' i.e. Hsl)?

== {dark,light}Contrast
We need a method to provide a suitably contrasting color. The easiest 
(and safest) way to do this is to either darken or lighten a reference 
color, making the decision based on a preference and ability to achieve 
a specific level of contrast.

Usage:
Right now the only use I know of is in dolphin. Styles really need the 
'shade' superset of this (see next topic).

Questions:
Chainging Y (luma) only is simplest and often "most aesthetic" 
especially when the needed contrast is low-to-medium (i.e. the disk 
usage indicator in dolphin). For higher-contrast situations, should we 
also provide a version that generates a complementary (hue+180 degrees) 
color? What about complementing saturation?

== shade
To generate distinct colors for use in 3d effects, we need a way to 
generate the four color light, midlight, dark and shadow from a base 
color. The most straight-forward way seems to be to provide all four at 
once to ensure that midlight and dark don't end up being the same (i.e. 
when the base is too dark to use darker colors for dark and shadow).

Usage: styles

Questions:
What should the API look like? Should it take contrast and use 
2*contrast for light if dark is lighter than base? A 'median' might be 
'dark contrast', optional 'light contrast if dark is darker' and 
optional 'light contrast if dark is lighter'.

== focus color
We would like the control that has input focus to (optionally) be drawn 
in a different color. Frames I think should use 100% the color, lighter 
or darker as appropriate (i.e. use the color as base, then shade as 
usual). Backgrounds may be better done as a tint of the base color with 
the focus color (this helps keep the foreground colors legible as well).

Usage: styles

Questions:
Should we allow changing the tint amount of backgrounds at a global 
level or allow styles to control it? In the former case, we can create 
KColorPalette that tints automagically from QStyleOption (but the style 
has less control), otherwise styles need to handle this themselves.

While we're at it, can we add mouse hover color as a global setting?

== color roles
Currently we have a problem that applications wanting to distinguish 
items by color have to invent their own system to do so, often leading 
to hard coded colors. The suggestion (1) for dealing with this is to 
have eight 'roles' (which would include the current "normal", "link" and 
"visited"), IOW you now get colors via foo.role(BackgroundRole, 
ColorRole) (note: ColorRole can also be 'Background').

Usage: many, many potential users :-)

Questions:
What do we name the five sets? We have "window"*2 (e.g. text edit, 
menus, both ow which might be called "window"), "button", "selected" and 
"tooltip". How do we look up colors? We could build KColorPalette (see 
also above) although maybe KStylePalette would be a better name? This 
would be nice because we could fold in shade (above), but may cause 
problems if someone is overriding the color palette. We could use also 
either KGlobalSettings or KColorUtils (which I am assuming will hold 
e.g. {dark,light}{en,Contrast}, shade, luma, contrast, etc).

Notes:
In addition to the eight foreground roles (which includes "normal"), 
there are additionally the roles Background, AltBackground, 
FocusBackground and (I would like to add) ActiveBackground for each 
role. Then there are light, midlight, dark, and shadow. It might be 
beneficial to define these for each background set but that seems 
overkill. We should allow everything to inherit from background set 0 
(one of the 'window's).

[1] http://amen-online.de/%7Eolafschmidt/colors/colors.pdf

-- 
Matthew
"In the beginning was the word, and the word was
content-type: text/plain" -- Martin Schulze