On Wed, 07 Jun 2000, Sven Neumann <[EMAIL PROTECTED]> wrote:
> [quoting Austin Donnelly <[EMAIL PROTECTED]>]
> > > I would be very unhappy if changing the layer opacity from 100% to 50%
> > > would eat up a dozen or more undo-steps since each value_changed signal
> > > from the slider triggers an undo which causes another undo-step fall 
> > > off the end of the undo queue. 
> > 
> > Oh, sure - that's clearly a bad idea.
> > 
> > I was thinking of only pushing the undo when you release the slider.
> > That doesn't help those using the keyboard to nudge the slider though.

This would not really solve the problem anyway, even if you are using
the mouse.  Often I play with layer modes and opacity in order to get
the effect that I am looking for.  So I click on the slider, then
select something in the modes menu, then move the slider again, and so
on...  It would not be a good idea to save all these individual
changes on the undo stack, because there are too many of them and I am
not interested in saving the current state of the image until I start
some painting operations.

> I still believe that it is a bad idea to waste undo steps for operations 
> that don't save any shadow tiles. How hard would it be to change the 
> undo system so that the number of undo steps is calculated only from
> "real" undos? What about the idea of merging consecutive changes to the
> layer attributes into one?

Here is my proposal: save and restore all layer attributes (opacity,
mode, keep trans, visibility) together with any operation that is
currently put on the undo stack.

This means that if you do anything that starts an undo step
(e.g. painting in the image), the current attributes of all layers are
saved on the undo stack.  After finishing your painting operation, you
can modify the visibility or mode of any layer and nothing will be
saved on the undo stack... until you start another undoable operation
and then the current layer attributes are saved again at the same time
as the new undo step is created.  Later, if you undo the last
operation, then the image is restored and simultaneously all layer
attributes are reset to the values that they had before.

I think that such a behaviour would be acceptable to the users.  It
would also fix the bug that I described earlier and that is affecting
the undo-aware scripts, because undoing the changes to the image would
also restore the layer attributes to a sane state (as they were before
the script was called).

The annoying problem with the current code is that if you perform
several operations on an image, then change the attributes of some
layer, then undo some of all of these operations, you get an
inconsistent result: the tiles of the image are as they were before
you applied all these operations, but the layer attributes are still
in the same state as after the last operation.  This is not easy to
explain to the users...


Reply via email to