Color roles, coming this Monday to kdelibs?

[Simon Hausmann]

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. In Qt 
we often tend to repeat the enum name in the enum values. For example

enum ItemFlag {
    ItemIsSelectable = 1,
    ...
};

we prefer over just

enum ItemFlag {
    IsSelectable = 1,
    ...
};

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.

But I am wondering for this API: How exactly do applications use this? Can you 
post some example code? How much of this can be enforced/covered by the style 
and how much do application authors pay attention to the colors by the use of 
this new API?

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

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();

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.


Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070608/57154487/attachment.sig>