On Fri, Feb 25, 2011 at 1:17 PM, Steve Bennett <[email protected]> wrote:
> Does this absolutely have to be the case? I can't quite understand, > from a theoretical point of view, why this principle is necessary. Why > not add the action to a stack, and also carry it out now? What's the > benefit of maintaining the current state as long as possible, then > doing all the actions in one flurry? This is where I could be wrong, but I think that it's critical to the redo part. When undo'ing an action the action is added to the redo list, so if adding an action has side-effects that'll blow up during redoing the action. Also, if the action works based on side effects that aren't tracked within the action itself, then it won't work properly when being redone. Hence everything needs to be done by adding things to an action, and it needs to be completely self-contained so it can be moved back and forward between the different stacks. But I might be wrong. > And just to add a bit more incoherent rambling, would a simpler model > be, instead of passing around these stacks everywhere, to have just a > main undo stack with two functions: > 1) RecordAction which adds an action to the undo stack, and carries it out. > 2) FinishUndoBlock, which groups all actions since the last time it > was called, into one block, which will all be undone with a single > keystroke. Sort of the equivalent of closing a changeset. That's just an unclear representation of a composite action! The RecordAction is undo.push, the FinishUndoBlock is MainUndoStack....addAction(), and the carrying-out-before-we're-finished is the bad idea that we need to avoid. > But, since I clearly don't understand how this stuff works, these > impertinent suggestions may be completely off the mark. Since I barely understand how it all works, but it certainly does work, I tend to just try to figure it out! When (if) I ever get to the point where I fully understand it then I might change my mind, but I'm not there yet. Cheers, Andy _______________________________________________ Potlatch-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/potlatch-dev
