blend function urgently needed in kdelibs

[Matthew Woehlke]

Thiago Macieira wrote:
> Matthew Woehlke wrote:
>> kdelibs desperately needs a color blending function. I am working on it,
>> planning to have it go in Monday, May 28.
>>
>> blend() is reasonably complicated, but the colorspace conversion
>> functions are some of the biggest hitters in terms of code volume. I
>> already have rgb<->hsl (and I think rgb<->hsv, but those are common), I
>> need rgb<->hsy yet but hsy is very similar to hsv. Anyway, since some
>> commented it would be nice to see some actual code, I'm attaching what I
>> have so far...
> 
> Comments:
> 1) You're mixing the enums. ColorSpec is declared in a flag-like manner, 
> but it has no Q_DECLARE_FLAGS; BlendMode or BlendFlags (choose one) is 
> declared in a non-flag mode but has Q_DECLARE_FLAGS. You want to review 
> that.

Thanks, but that's actually intentional, it should not be used as flags 
except by KColorPrivate (although Matt Nowell is doing his darndest to 
talk me out of that :-)). I guess making it 'not flags-like' would mean 
'making the values 1, 2, 3, ...'? (I want to confirm because I may end 
up going that way...)

> 2) Please remove the protected function and the static inlines. They have 
> no business being in a public header file.

Then where /do/ protected functions belong? (What if someone wanted to 
subclass KColor?)

I suspected someone would complain about the static inlines, the thing 
is I would like them to be available... are they OK non-inline? (It's 
not like they're going to change, though...)

> 3) Constructors must be explicit or explicitly implicit. (i.e., add the 
> krazy mark if it's to be implicit)

I must admit I'm not entirely familiar with what the difference is, how 
do I know which should be which? Is there a doc somewhere?

> 4) If you want implicit sharing, use QSharedDataPointer.

See conversation with Matt Nowell, this is still in the air.

-- 
Matthew
"Nobody expects the traditional Bourne shell!"