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