Looks like a release schedule to me

[Casper Boemann]

> > * Painting on displaced layers
> The patch tries to resolve the issue as follows. Instead of letting the
> calculations with the offsets be done in the merging and flatten code, it
> puts that in the PixelIterators. This way, every piece of code that
accesses
> a paintdevice using its iterators, gets the right piece of the layer. That
> is, if it asks the coordinate (0,0), it gets the piece of the layer that
is
> displayed in the image at that coordinate (before, it would get that
> coordinate of the layer itself, which is now even more useless than before
> with the auto extending layers).
>
> The only thing I'm not sure about, if this is the right place (or the
right
> way) to fix this. I put it in the iterators code because I think almost
every
> part of the code uses them, but I could be mistaken about that.

I don't think it is the right place and way to fix this. At least extend()
needs to be fixed in the same way then (I havn't looked at the code if you
have already done that)

But more fundamentally it hides the layer offsets in a way that may be
confusing and problematic in the future. It does thing behind our backs and
that worries me.

Remember that iterators must also work on paintdevices. You patch does work
on paint devices, but I would like the (layer)offset to be moved to the
layer class, and then your fix would be a problem.

The fact that we must also change extent to make your fix work, suggest to
me that it is too complicated. (eventhough the idea and implementation is
simple)

So my suggestion would be to let the layerclass have coordinate transforming
functions, and to transforn the coordinates on an as-needed basis inside
tools, plugins etc.

Just my two cents worth.

best regards
Casper Boemann