koffice/krita

[Boudewijn Rempt]

On Friday 27 August 2004 14:26, Bart Coppens wrote:
> Quoting Boudewijn Rempt <boud at valdyas.org>:
> > virtual void KisStrategyColorSpace::bitBlt(Q_INT32 stride,
> > virtual void KisStrategyColorSpace::bitBlt(Q_INT32 stride,
>
> Wouldn't it be better to have these return a boolean or some sort of error
> code? So plugins and other code can try to use a composite op, and know
> immediately if it failed (because the strategy doesn't support this
> operation). You could let the calling code do this check, but that would
> lead to code duplication, I think.

Since the composite ops that can be used with a particular color strategy can 
be listed beforehand (and, for instance, used in the composite op combobox 
for tools and layer props, I think it would be not just an error condition, 
but a bug in the code if an unsupported composite op was used in the call.

>
> > is all the API I want the color strategies to expose to the rest of
> > Krita.
>
> I agree that the API for color strategies should be minimal, but with only
> these functions you'll miss certain functionality (think of the
> KisToolFill::difference function), that should either depend on the
> strategy directly, or indirectly through KoColor (depending on how colors
> will be implemented).

Oh, I think I was unclear. I was only writing about the composite op part of 
the API, not the rest.

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20040827/0f600ac7/attachment.pgp