blend function urgently needed in kdelibs
mw_triad at users.sourceforge.net
Tue May 22 15:49:26 BST 2007
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...
> 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
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
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.
"Nobody expects the traditional Bourne shell!"
More information about the kde-core-devel