Color roles, coming this Monday to kdelibs?

[Matthew Woehlke]

Simon Hausmann wrote:
> On Thursday 07 June 2007 00:58:46 Matthew Woehlke wrote:
>> As per the usability recommendation (1) and the original thread (2), the
>> attached patch adds color roles to KDE. There are still things to do,
>> like find things this breaks (I am guessing color schemes), find places
>> that need to use it (anyone using hard-coded colors has buggy code
>> according to u7y/a11y), and of course add something to configure them
>>
>> :-), but these are not API changes (probably not even BIC).
>>
>> There are probably lots of users of most of the deprecated functions and
>> that is OK, they can keep using them in KDE4 :-). We /might/ want to
>> kill off KGS::calculateAlternateBackgroundColor if its replacements are
>> ready for KDE4.0 but that is for next week (there are only two users
>> shown by LXR, one of the three not-KGS hits is only a comment).
>>
>> According to aseigo (3) it is OK to change where the colors are stored.
>>
>> Also, if anyone has better suggestions for the implementation (like, a
>> way to avoid macros w/o dozens more lines of code), please share :-).
>>
>> 1: http://amen-online.de/%7Eolafschmidt/colors/colors.pdf
>> 2: http://permalink.gmane.org/gmane.comp.kde.devel.core/42908
>> 3: http://permalink.gmane.org/gmane.comp.kde.devel.core/42933
> 
> This looks interesting, but I think the enum values have unfortunate generic 
> names. If you just see KGlobalSettings::View in application code it's 
> impossible to know that this refers to a color set just from the name.

Well, this won't happen. :-) Rather, you would see e.g:
KGS::color(KGS::View, KGS::ForegroundNormal)

That is, I don't expect to see this used outside of KGS::color.

Um, here is a dumb and trivial solution, what if the enum's belonged to 
a namespace containing just the enum? So you saw instead...
KGS::color(KColorSet::View, KColorRole::ForegroundNormal)

(In fact, I'd like to do at least that, if no one objects. KColorTheme 
is still being considered :-).)

> Now in this case it's not entirely obvious without ending up with extra long 
> names, which I think often indicates that the enum is incorrectly placed in 
> the namespace/class hierarchy.

Hmm... if you have a better idea, please share :-). We could move 
everything (or just the enums?) to KColorUtils, although color() itself 
IMO makes most sense belonging to KGS, especially since that's where the 
old getSomeGlobalColor functions live.

> But I am wondering for this API: How exactly do applications use this? Can you 
> post some example code?

Not example code, but did you see this?
http://permalink.gmane.org/gmane.comp.kde.devel.core/42910

> How much of this can be enforced/covered by the style 

Styles are mostly concerned with FocusTint and HoverTint (and possible 
ForegroundInactive). Presumably the link-drawing code is also 
standardized. Otherwise...

> and how much do application authors pay attention to the colors by the use of 
> this new API?

...it is mainly the job of applications to pay attention to it, yes. I 
don't think this is a big deal, since currently an application needing 
this either already has some form of config, in which case this is 
potentially simplifying code, or is using a hard-coded color (which is a 
usability/accessibility bug, and I believe a violation of the KDE4 HIG 
standards as well).

> Would it perhaps be simpler to create a KColorScheme class that has shorter 
> but more descriptive accessors?

Maybe. :-) Are there other agreements as well? (Disagreements?)

> For example:
> 
> QColor bg = KGlobalSettings::color(KGlobalSettings::View, 
> KGlobalSettings::BackgroundNormal)
> QColor alt = KGlobalSettings::color(KGlobalSettings::View, 
> KGlobalSettings::BackgroundAlternate)
> 
> versus
> 
> // use the same terminology as in the HCI
> KColorScheme scheme(KColorScheme::ButtonColors);
> QColor bg = scheme.backgroundColor();
> QColor alt = scheme.alternateBackgroundColor();

Ok, had to read that twice. Hmm... not a problem I guess to add methods 
for new roles instead of enum values, so ability to improve w/o breaking 
BC is not affected. I think however there would be two ways to construct 
such a class; get one from KGS, or feed it a QPalette as input (the 
latter being useful for styles).

> But I admit I'm doing a lot of guessing here since I don't know _how_ and 
> _when_ exactly applications use this. That was unfortunately missing from 
> your initial mail.

I'm guessing you missed the message I linked above?

-- 
Matthew
"In the beginning was the word, and the word was
content-type: text/plain" -- Martin Schulze