Solving the colour scheme issues properly

[Olaf Schmidt]

Hi!

While KColorScheme is an improvement over what we had in KDE3, it still leaves 
some issues unsolved. My original attitude was that we do not need to address 
all of them just now, since the timeframe for KDE 4.0 is short and we still 
have KDE 4.x, but Maksim's e-mail convinced me that we should at least 
discuss them now to reach a full understanding of the situation.


Problem 1: KDE applications that are run as a different user (sudo) or 
remotely over the network do not have access to the KDE settings of the 
desktop they run in.

Problem 2: KDE applications running in GNOME do not pick up the user-chosen 
colours and look out of place. Non-KDE applications running in KDE can only 
pick up the user-chosen KDE colours if they parse the configuration files.

Problem 3: Qt applications running in KDE are usually painted with KDE styles 
but do not follow the user chosen KDE colour settings, which leads to 
inconsistencies.

Problem 4: Some HTML pages define text and background colours that do not have 
enough contrast with the user-chosen highlighting colours (selection, focus, 
hover). The same applies to text in documents, or to other places where the 
global colour scheme is (correctly or incorrectly) not used.

Problem 5: KColorScheme has two sorts of colour roles:
a) colours that are intended for applications (ForegroundRole and 
BackgroundRole) and will be passed on to styles by changing the QPalette of 
an item
b) colours that are mainly useful for styles (DecorationRole and ShadeRole) 
and which cannot be passed on to the styles via the current implementation of 
QPalette


Idea A (for problems 1-3): 
Plasma sets an Xatom name for each colour role. All applications running on 
the same X display can access these. We should try to agree with GNOME on a 
shared naming convention to achieve a freedesktop.org standard.
See http://en.wikipedia.org/wiki/X_Window_core_protocol#Atoms
(This idea has already been discussed by some GNOME developers, but I do not 
know whether they have implemented it.)

Idea B (for problems 3-4):
KDE styles that use special visual effects for focussed, hovered or selected 
items must be able to check whether the colour they use for the effect has 
enough contrast with, and modify the colour otherwise. This can be done with 
the functions in KColorUtils (e.g. contrast and tint).

Idea C (for problem 5):
We replace DecorationRole and ShadeRole with convenience functions that create 
fitting and accessibility-conformant decoration and shadow colours from a 
given QPalette. The decoration function would work similar to the tint 
function in KColorUtil: It would combine the brightness of the passed text 
and background colours with the saturation and hue of a global focus/hover 
setting (passed via an Xatom name again).


Please keep in mind that I am not a real developer. My area of expertise is 
accessibility. My job is to identify accessibility issues that need to be 
fixed. It is your job to find the best implementation for it.

I discussed ideas A and B with one of the Oxygen style developers (Riccardo) 
to check that this not complete technical nonsense, but I do not claim that 
they are the best possible solution. If you have better suggestions, then 
please share them.

Olaf