Color manipulation functions in kdelibs?

[Matthew Woehlke]

Zack Rusin wrote:
> On Thursday 14 December 2006 11:54, Matthew Woehlke wrote:
>> Have you read the thread on kde-usability about how we need to provide means 
>> to generate 'accessible' colors that fit in the user's current color scheme? 
> 
> Nope, I find it silly when people split the same discussion on the same list. 
> I did go over it now and don't see absolutely anything in it that would force 
> those methods in kdelibs and not in Qt or that would even imply their 
> incredible importance. 

Are you colorblind? If so then I will humbly concede the point. If not, 
I will submit that if you were, you might feel differently. :-) I 
suppose as someone that is used to being burned by hard-coded colors (a 
different issue totally unrelated to this discussion) I have a certain 
degree of sympathy in this area.

The real point is that we (or at least, I) don't know right this instant 
what /exactly/ the usability folks are going to need. In fact, if you 
/really/ look at the original thread, it looks like major sweeping 
changes in QColorGroup would be very beneficial to their cause... but 
for now at least, I don't want to try to tackle that.

IOW, my objection is partly one of time and testing (by which I mean 
'testing on the user's side: does this design work well?' sort of 
things). If we knew exactly what was needed, I would probably feel 
differently about wanting to keep this in kdelibs as opposed to pushing 
it up to Qt. As is, I am worried that this won't be settled by KDE4, or 
likely even within the first few official releases, which invites the 
'4.0.1 needs a newer Qt than 4.0.0' trap that I would prefer to avoid.

But if you think you can get the usability group to pony up some specs 
in time to avoid that, then by all means, let's shoot for Qt. (And let 
me know if I can help prod ;-).)

-- 
Matthew
What? This signature /again/?