Color manipulation functions in kdelibs?

[Zack Rusin]

On Wednesday 13 December 2006 11:54, Matthew Woehlke wrote:
> Eh? Qcolor::dark and QColor::light do not work the way I need them to,

heh, well, lets figure out how to make them work the "way you need them to".

> HDR is not supported, there is no HLS or HSY support at all, and if

HLS and HSY isn't really necessary for any kind of desktop usage, is it? i'm 
just wondering whether there is an actual need for it or whether it's just 
something that would be cool to have. 

> there is a blend, 

right, blending is not a property of color, it's an action (aka. function) one 
issues on drawable surfaces. And as such has no place in color classes, but 
in surface (aka. image) manipulation library.

>
> Besides, I'm still inclined to want the blending functions in kdelibs
> rather than Qt, if for no other reason than to allow new functionality
> to follow KDE releases rather than Qt releases. I would much rather an
> application/decoration/style depend on a particular KDE version than a
> Qt version.

Well, that's already the case so it's not adding any new functionality. 

> I thought HDR used floating-point? 

There's quite a few HDR standards. 

> And I know I already mentioned both 
> 16-bit color and HDR color. Although, if you read the QColor doc
> closely, you will see it is already 16-bit, it just provides no
> accessors for the data.

You realize I work on it, right? :) It's not that I don't appreciate a run 
down of how our code works, but you'll just need to trust me when I say that 
it's actually a little more to implement 16bpc support :)

> I submitted a pair of "bugs" for QColor HLS and HSY spaces, and for HDR
> support. But you haven't convinced me that putting the revised blend in
> QColor is a good idea.

Probably because I never wanted to and was never doing that. We won't add 
blend method to color because that's not where it should be. Blending pixels 
is an absolutely trivial operation that needs no function, but then again no 
one blends one pixel with another. People blend drawables. For that we need a 
decent image manipulation framework in KDE. For now we don't have it, so the 
discussion imho is moot. 

z