Color roles, coming this Monday to kdelibs?

[Simon Hausmann]

On Friday 08 June 2007 16:32:52 Matthew Woehlke wrote:
> 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.

Sure, that is clearly an argument in favor of having the enum in the same 
namespace as the method that returns the actual color. I still think though 
that KGlobalSettings is the wrong namespace.

My point remains, when you read

KGlobalSettings::color(KGlobalSettings::View, 
KGlobalSettings::ForegroundNormal)

you have to ask yourself: What is 'View' in the context of KGlobalSettings?

It's impossible to guess it just from the name, you have to look it up in the 
docs.

KColorTheme::InputWidgetColors or similar is closer to being self-explaining 
IMHO. The relationship with global KDE settings is IMHO less important than 
the fact that there are different colors for different types of widgets.

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

I think that's even more confusing. You have to learn about KGlobalSettings 
_and_ another namespace.

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

A method that takes an enum is probably just as fine, as long as it isn't in a 
completely unrelated namespace IMHO (KGlobalSettings).

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/20070611/6c235ca8/attachment.sig>