Color manipulation functions in kdelibs?

[Matthew Woehlke]

Brad Hards wrote:
> On Saturday 09 December 2006 08:27, Matthew Woehlke wrote:
>>> QColor blendRGB(const QColor& c1, const QColor& c2, double k,
>>>                  bool trunc=true)
> <snip>
>>> Blends between two colors in the specified color space. 'k' is the blend
>>> factor, e.g. k=0 gives c1, k=1 gives c2. If 'trunc' is false, allow
>>> values < 0 or > 1 (otherwise clamp to [0, 1]), e.g. blendRGB(Qt::gray,
>>> Qt::white, -1, false) gives Qt::black, blendHSV(Qt::red, Qt::green, 2.0,
>>> false) gives Qt::blue, etc.). If either color is Qt::white or Qt::black,
>>> then HLS/HSV treat it as having H and S equal to the other color.
> I would never have guessed that.
> How about something like an enumeration that has a range of outputs options 
> like:
> KColorBlend::limitBlendOutput, KColorBlend::extremeBlendOutput, 
> KColorBlend::accessibilityLowContrast; KColorBlend::accessibilityHighContrast
> and so on. Then you use the right enumeration for the purpose you are trying 
> to achieve.
> 
> The k value should be called blendFactor in the declaration.
> 
> This might also be better placed in the QColor code - have you submitted a 
> wishlist item to the Trolls?

Perhaps, but then you are tying KDE4 to a version of Qt that does not 
yet exist, and also relying on Trolltech to maintain the functions we 
need. Is that really a good idea? It is my understanding that 
historically KDE has not been tightly tied to a particular release of 
Qt. If we took this route, and, using your example above, realized we 
needed a new blending mode, then the next KDE release would suddenly 
depend on a roughly simultaneous Qt release. Putting them in kdelibs 
means that a particular KDE application would need a particular release 
level of kdelibs, which seems much more reasonable. In fact, I expect 
this behavior, whereas I currently do not expect to have to update Qt to 
update KDE.

I'm happy to submit a wish to Qt. In fact, I think they should probably 
have a reasonable subset of this functionality *in addition* to having a 
more complete suite in kdelibs, but in Qt I would expect maybe just 
'blend' (RGB space) that either always truncated the factor or always 
forced the caller to do so explicitly (Qt::clamp - borrowing GL 
terminology - would be handy). Maybe having 'blendHSV' also would be 
nice, and having HLS stuff would really be icing. But once you get into 
HLS, you get into having 'true gray' correction, which is starting to 
get a little heavy for Qt. In case I hadn't mentioned, the 'lighten' and 
'darken' that I want depend on HLS conversion to function properly, 
since the intent is to change L without changing H or S (which merely 
blending with white or black would do).

And, for usability reasons, we do *need* 'true gray' handling for HLS.

-- 
Matthew
"Lost a planet, Obi Wan has? How embarrassing..."
  -- Yoda (Star Wars II: Attack of the Clones)