finalizing the Iterator API

[Boudewijn Rempt]

On Tue, 6 Jul 2004, Cyrille Berger wrote:

> > >From you experience with the other iterators, are there anything you would
> >
> > like to change navigationvise - now that we have the chance..
> >
> > GOF uses done() to check for reaching the end. You use another iterator to
> > compare with. GOF also lists your method as an alternative (also lists an
> > alternative of advance() returning a status) so I'm not saying there is
> > anything wrong. It's just a matter of taste, and now that you have had some
> > experience with use, you might have som wishes.
>
> Unfortunatelly my experience has been "polluted" by the STL, which use begin()
> and end(), and Qt et kdelibs use also begin() / end(), so I think we should
> keep them.

That's a very strong argument, so let's keep it consistent with our environment.

> As for the ".h", here is my opinion :
> * I don't see the difference between KisPixelIterator and
> KisPixelRectIterator.

>From what I understand, the rect iterator iteratos over a part of the paint device.
I may well be misunderstanding something.

> * the reason why I made two iterrators (one for the line and one for the
> pixel) was that it might be usefull to skip a line or to go back to the
> beginning

I'm not sure about the need to skip a line; there's a lot of need to be able to
move in arbitrary directions, i.e., follow a path through the image defined by up,
down, left, right, up-left, up-right, down-left, down-right. What would be really
great is the ability to have the iterator follow the path defined by a vector
or a curve. But I haven't got the faintest clue about how to do that.

> * I think that iterrator should not return a pointer, but they should be able
> to give the value of a pixel and to modify it so that why I started to add
> the two following operators :
> 	operator QUANTUM ();
> 	operator=(QUANTUM v);
> * I do really think that we need an operator that return a class representing
> a pixel, a class which look like this :
> class PixelRepresentation {
> 	public:
> 		operator[](Q_INT32 a);
> 		operator=(PixelRepresention a);
> }
> which may be use like this :
> PixelRepresentation a;
> PixelRepresentation b;
> a[RED] = 0.2*b[BLUE] + 0.6*c[RED] + 0.2*c[GREEN]
> a[BLUE] = 0.4*b[BLUE] + 0.3*c[RED] + 0.3*c[GREEN]
> a[GREEN]= 0.6*b[BLUE] + 0.1*c[RED] + 0.3*c[GREEN]
> b = a;

These two points go together, I guess. One thing I really want to get rid of is the
whole [BLUE], [RED], [GREEN], [INTELLIGENT_SHADE_OF_BLUE] idiom; interpreting the
channels is the colour strategy's job, and no doubt we can find a more elegant way of
working with pixels or colours. A truly universal pixel representation is perhaps
hard to invent: the closest I can come is a vector of channels, where a channel can be
a byte, an int, a double or a float.

>
> as for accessing to the tilenumber by (col,row), i don't understand why it is
> useful?
>

I wouldn't know myself here: the whole idea is to hide all the tiles behind the iterators,
but perhaps it has to do with the auto-extending layers Casper is building, and if that's
the case, his preference should go, I think.

We should also think carefully about how deep we want to hide the undo information. Undo
information is stored as tiles, not as arbitrary rects, which argues for hiding deeper down
than KisPainter.