Color roles, coming this Monday to kdelibs?

[Matthew Woehlke]

Fredrik Höglund wrote:
> Would you consider reusing the names for the color roles that are
> already in QPalette, so programmers who use our API's don't have
> to learn two names for the same thing, and keep track of which
> name is supposed to be used where?

The problem is that the Qt names are already a mess of inconsistency. We 
can either Do It Right, or exacerbate the problem. Now, I'm not saying 
that following Qt isn't worth the headache :-), I just want to make sure 
we have a clear consensus that's what we're doing, and why. However 
unless that happens in the next two hours, the enums stay... for this 
week anyway.

> How do you intend to pass colors (for example focus tint colors)
> that aren't in QPalette down to the widget style? I'm assuming here
> that you intend for widget styles to use these colors.

Unfortunately, there is no way to do this AFAIK, but that's no worse 
than the current situation where these colors are not even system-global 
but only style-global. (I happen to be of the opinion that no style 
should need to pay attention to the palette anyway; that using the 
system-global settings instead should not be a behavior change and that 
if it is, an application is misbehaving... but I'm not saying that I 
advocate that :-).)

> Have you discussed with Trolltech the possibility of extending
> QPalette with these new color roles?

The proposal has been out there for a while; I'm not sure what exposure 
TT has had to it, but based on my experience trying to get other such 
functionality implemented, well...

Personally I'm hoping that KDE doing it in 4.0 will motivate TT to 
follow us :-)... eventually. But I'm not holding my breath. (Also, as 
per the first paragraph, doing it /well/ isn't BC for TT unless they 
deprecate a bunch of methods.)

-- 
Matthew
Ngx iqct zgg dxei zodt gf ngxk iqfrl.