finalizing the Iterator API

[Cyrille Berger]

> >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.


As for the ".h", here is my opinion :
* I don't see the difference between KisPixelIterator and 
KisPixelRectIterator. 
* 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 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;

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

-- 
--- Cyrille Berger ---