Color roles, coming this Monday to kdelibs?

[Fredrik Höglund]

On Tuesday 12 June 2007 00:13, Matthew Woehlke wrote:
> 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.

I agree that some of the color roles in QPalette aren't optimally named,
but your proposed color roles don't really fix this. For example the
Button role in QPalette is really the 3D element role, and the widget style
is supposed to use it for toolbars etc. in addition to just buttons.

But in my opinion having two API's with two sets of names for the same
thing does exacerbate the situation.

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

I'm afraid I don't understand what you're saying here. You're adding color
roles that are meant to be used by styles, but they can't actually be used
by styles, but that isn't really a problem?

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

I'd say probably none at all, unless you've submitted it directly to qt-bugs
with an API proposal, or to someone at Trolltech and explained that you
want to see this in Qt.

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

Additional color roles can be added without breaking binary compatibility,
because that's how the API is designed. And changing method names in
QPalette isn't something that needs to be done to implement these
features.

Adding something like a KPalette class that essentially provides the same
functionality as QPalette also goes against previously stated goals for
kdelibs in KDE 4 IMHO.

Regards,
Fredrik