Solving the colour scheme issues properly

[Matthew Woehlke]

(Key: KCS==KColorScheme, KCU==KColorUtils, KGS==KGlobalSettings)

Olaf Schmidt wrote:
> 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.

Actually, I don't consider that a problem :-). I like having different 
colors for different users (it's a good visual indicator), so if we do 
anything about this, please make it something that can be disabled. But 
obviously it is an a11y issue and should be addressed.

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

Over here, both Qt and gtk applications are using my basic color scheme 
(missing not-in-Qt idiosyncrasies of course, but we're talking about 
that elsewhere in this thread). What am I missing?

> 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

This isn't really true, KCS::shade() is used by 
KGS::createApplicationPalette, so IMO it is about equally useful for KDE 
applications and styles. Currently, the KCS(Window).background() set of 
shades should be equal to what is in QPalette unless the app is doing 
screwy things. Otherwise note that there is KCS::shade(QColor) which is 
already operating on a color passed in by the caller... I think this is 
what you are asking for in (C)?

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

Sounds like a plan, basically we have what we need, we just need a usage 
policy?

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

I don't think I want to *completely* jettison the raw accessors. The 
"today" solution is KCS::decoration() + KCU::tint. I guess we could add 
a convenience decoration() overload that takes a base color and 
generates a suitable contrasting color from that? Or is that too much 
redundancy?

(Btw, did you ever look at the proposed tint algorithm? I did check it 
in today, after not getting any feedback.)

As for KCS::shade(), as stated above, doesn't it already work this way? 
The base overload really isn't so much an accessor as a convenient, 
state-aware wrapper of the many-parameter one (in fact, if you look at 
the code that's exactly what it is).

-- 
Matthew
Sending this e-mail does not constitute endorsement of the contents; I 
may change my mind later.