are selections part of kispaintdevice or aren't they?
Cyrille Berger
cberger at cberger.net
Sat Oct 6 20:03:04 CEST 2007
On Saturday 06 October 2007, Boudewijn Rempt wrote:
> I've been sleeping on this. Passing a selection as a parameter to the
> iterator sounded like a good thing at first, but then I thought, it would
> only complicate the code. We'd still need ot pass the selection to the
> filters and everywhere else. I'm not sure whether the convenience of
> isSelected() and selectedness() compensates for that.
I disagree with you, and the more I think about it, the more I am convinced
that it is a much better solution than having two iterators.
I mean, we will have
KisIterator itSrc = srcDevice->createIterator(...);
KisIterator itSrcSelection = srcSelection->createIterator(...);
KisIterator itDst = dstDevice->createIterator(...);
KisIterator itDstSelection = dstSelection->createIterator(...);
while(not itSrc.isDone())
{
...
++itSrc;
++itSrcSelection ;
++itDst;
++itDstSelection
}
against :
KisIterator itSrc = srcDevice->createIterator(..., srcSelection);
KisIterator itDst = dstDevice->createIterator(..., dstSelection);
while(not itSrc.isDone())
{
...
++itSrc;
++itDst;
}
So no, I do think that having the selection at iterator level brings more than
the two function convenience.
But, then for the API of KisFilter::process, we are allready passing six
parameters (source device, source origin, destination device, destination
origin, size and configuration), and adding selection would mean two more. I
think we should consider passing a KisFilterProcessingInformation structure
which would contain the device, the origin and the selection (and would be
extensible if we found other thing to pass in the future without suffering
and editing all filters).
--
Cyrille Berger
More information about the kimageshop
mailing list