Solving the colour scheme issues properly

[Olaf Schmidt]

[ Matthew Woehlke, Di., 3. Jul. 2007 ]
> 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?

On the LSB list, some ISVs have asked for easy access to the colour and font 
configuration to integrate well with both KDE and GNOME. Not all of those are 
using Qt or gtk (and our gtk colouring is seriously broken with some colour 
schemes).

The XSettings solution could actually be standardised and would move the 
responsibility for the integration to the ISVs (rather than requiring us to 
do half-working hacks).

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

Yes, I think so.

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

Yes, exactly, we need to make it far easier (and better documented) who 
exactly style authors and application developers can get the various colours 
they need (e.g. focus/hover text colours, more background colours).

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

Yes, please add a convinience functions for
KCS::foreground() + KCU::tint -> background
KCS::decoration() + KCU::tint -> focus text
KCS::decoration() + KCU::tint -> focus background
KCS::decoration() + KCU::tint -> hover text
KCS::decoration() + KCU::tint -> hover background

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

Do you have a testing application for it?

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

OK.

Olaf