On Wed, 07 Jun 2000, Sven Neumann <neumanns@xxxxxxxxxxxxxxxxxx> wrote: > [quoting Austin Donnelly <austin@xxxxxxxx>] > > > 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... -Raphael
