Color roles, coming this Monday to kdelibs?

[Matthew Woehlke]

Fredrik Höglund wrote:
> 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.

Um? The Button role is for buttons and also IIRC things like dropdowns 
(QComboBox), etc, but not for all 3d things hence the Window role. 
Anyway you still have two weeks to suggest a better name :-).

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

Right now, styles have The One True Value for e.g. hover color that is 
specific to that style. Now e.g. there will be a place to centrally 
configure that. Besides, 99% of the time a widget's palette == the 
system palette and there is no problem.

Foreground roles are different because those I don't think should be 
used by styles but by applications, that have control over the palettes, 
so... yes, I don't expect this to be a problem :-).

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

...except we're stuck with things like 'base' and 'foreground' that are 
not consistent with the naming scheme otherwise :-(.

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

Um... it doesn't? It provides functionality that was already in 
KGlobalSettings, and it provides a bunch of entirely new functionality 
that never existed before. Unless I am confused?

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