Multiple undo and redo

[Marielle Lange]

Richard,

Thanks for all these details. The state approach is something I am  
keen on investigating as well. I know that Andre in a previous  
discussion had discussed the idea of storing and restoring states.  
Was this solution implemented or were there only ideas being discussed?

Malte, what did you do for drops, where you have 5 undos?

Anybody else on the list with programming undos? What are the  
different approaches possible. What are the pros and cons of each  
approach (works well for data / works for ui content)?

Marielle

> Most HI guidelines define an undoable action as one that affects  
> data, but operations which change selection do not affect the queue.
>
> But Rev operates differently:  If you move a button, then click  
> anywhere on the card or do anything else which changes the object  
> selection, executing an Undo command will not return the button to  
> its pre-move location.  In fact, the mere click off of the object  
> purges the Undo queue altogether (okay, maybe "queue" isn't the  
> right word for a single-item Undo, but I'm optimistic about the  
> future <g>).
>
> And not only is the undo queue purged, but when it changes as a  
> result of a selection change the undoChanged message isn't sent as  
> one would expect.
>

> When I think of good Undo architectures, I tend to think of good  
> frameworks.
[...]

> For example, being able to save object states would be great, esp.  
> if those objects can be containers like cards and even stacks.   
> Being able to store a container into a variable and restore it from  
> that variable would make the rest of managing Undo queues much  
> simpler.