Solving the colour scheme issues properly

[Maksim Orlovich]

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

XSettings might be a solution to these 2, but I am not sure the 'details'
are solvable, since different toolkits use different palettes. Fredrik can
say more than I do.

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

That really shouldn't happen for most apps, since we export the default
KDE palette to qtrc (of course, that stuff might need fixing in trunk).
I don't see what more we can do, and if the app feels like forcing a hot
pink palette.....

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

There is code in KHTML that tries to address that. Are there any instance
you know of where it doesn't work? Oh... DId you mean inside widgets, not
normal selected text?

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

Well, (b) is the technical problem, yes. The two sorts of roles is more of
an API design issue. Which is a concern too, since QPalette is confusing
enough, but KColorScheme has its own terminology. I'll skip commenting on
this part, though, since there are people better than me when it comes to
API design.

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

XSettings does stuff sort of like this. However, Plasma is probably the
wrong app to do it, kded will likely be a better fit.

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

I am not certain one can artificially construct an appropriate color that
would be sufficiently aesthetically pleasant and meet all the constraints
(e.g. contrast with foreground color, both different from bg color and not
/too/ different, different from highlight color, etc.). An another option
is to disable the effect, but that leads to inconsistency.

-Maks