finalizing the Iterator API

[Cyrille Berger]

* about iterators
Ok, here is my opinion, we needs two types of iterrator :
 - one with line/column (as we already have, and as most image libraries have)
 - one increasing pixel after pixel, is there a need for this type of 
iterrator to follow a line ? I explain, it would be faster if the iterrator 
go through a tile, and after the end of a tile go to the next tile


> * PixelIterators return a pointer to Q_UINT8 (not QUANTUM, since that is a 
> remnant from the days Krita depended on ImageMagick for its core, besides 
> that gives the impression of being interpreted data already.)
I disagree on this, PixelIterators should provide two operators, on that give 
the value and one that allow to set the value :
        operator QUANTUM ();
        operator=(QUANTUM v);

I thought that we have decided to keep QUANTUM until after the first release 
when we will search for the best solution to extend the notion ? (template or 
else)

> * Colour strategies interpret the data delivered by the iterators, they can,
> for instance, return a vector of channel values or a KoColor.
This is exactly what my class give :
class PixelRepresentation {
        public:
                operator[](Q_INT32 a);
                operator=(PixelRepresention a);
}

> * Colour strategies have a ChannelInfo object (which I'll extend tonight) 
that 
> describes the way *Q_UINT8 will be interpreted
In fact I add this object for dialog and especialy for use in the colorsfilter 
plugins.

>  * Ultimately, I want to get rid of much of the machinery in kis_global.h, 
like
> QUANTUM and its ilk, and the PIXEL_XXX definitions that describe the 
position 
> in an array of QUANTUMS for each channel.
I don't know what you find wrong with such mecanism ? I find they suit 
perfectly for RGBA, CMYN and grayscale. And you still need a way to determine 
to which channel correspond what.

* about friend class and KisTileMgr
> Huh, what do you mean ?
> If you mean a field in iterator, and that tilemgr provides appropiate access
> methods, then yes it can be done like that. But it also allows everybody
> else to use those access methods breaking encapsulation more than need be.
> Friend is not the thing I like the most about c++ either but it has its good
> points and this is one of them.

if KisTileMgr is store as a private field of KisPaintDevice and KisIterators, 
it can't break encapsulation.
If you remove the following two functions of KisPaintDevice, no one (except 
KisPaintDevice and the KisIterators) will be able to access directly the 
KisTileMgr :
        virtual KisTileMgrSP tiles() const;
        virtual KisTileMgrSP data();

-- 
--- Cyrille Berger ---