Color roles, coming this Monday to kdelibs?

[Matthew Woehlke]

Aaron J. Seigo wrote:
> there's a really unfortunate turn of conversation happening here. the colours 
> roles proposed by the usability team are not really about widget styles, but 
> rather use of colours within applications. see:
> 
> 	http://amen-online.de/%7Eolafschmidt/colors/colors.pdf
> 
> the only one of the new colour roles that i can see that might impact styles 
> is the focus colour.
> 
> the others are either the window decorations or content in application dialogs 
> and windows.
> 
> that this keeps getting dragged towards styles, both in the code and in the 
> conversation, is going to make it difficult to solve the primary problem 
> here: accessibility and consistency in the use of colours in applications.

I blame Simon :-). It's so very, very easy to put better shading in 
KColorScheme. But maybe we shouldn't do that.

I'd be ok with a struct-like class with just the four shades and maybe 
the original color, or if we're careful, maybe even put shade() straight 
in KColorUtils. But this discussion belongs here: 
http://permalink.gmane.org/gmane.comp.kde.devel.core/43099

> if we can focus on that issue, we might have a chance here =) 

Well, KColorScheme as I just checked it in effectively differs from the 
original proposal in one way: it lives in KColorScheme (which takes the 
set as a ctor argument) and not in KGlobalSettings.

Oh, and since KColorSheme uses QBrush (like QPalette), the accessors in 
KGS really *are* deprecated :-).

(Tomorrow, or at least "soon", I will see about updating the porting 
.html to talk about moving away from KGS to KColorScheme...)

-- 
Mathew
(sorry, .sig file is on the other computer)