Multiple undo and redo

[Richard Gaskin]

J. Landman Gay wrote:
> Ben Fisher wrote:
>> Create a new stack. Create two buttons.
>> Delete one of the buttons. Go Edit->Undo, and nothing happens. Imagine
>> if this button had all the scripts for your application. This is a
>> problem.
> 
> I didn't follow your recipe exactly, but I had a stack already made and 
> opened. I deleted a button, then chose "undo" from the Edit menu, and it 
> came back.
> 
> This has always been my experience, so there may be something else that 
> is preventing it from working.

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.

That latter item is a bug, but given the limitations of the current undo 
mechanisms in Rev I'm not sure it's worth fixing.

And with those limitations, the former issue of purging the Undo queue 
at unexpected times may not be a significant error given the nearly 
infinite range of things one might want to undo and how few are 
supported in the engine.

What's really needed is a fresh start on Undo as a whole.  At a minimum, 
there needs to be a message sent when the mouse is pressed outside of a 
control when the pointer tool is active.  While that small detail would 
solve a great many complexities with implementing Undo for layout, it's 
such a small baby step with so much more needed for other types of tasks.

When I think of good Undo architectures, I tend to think of good 
frameworks.  That's why I asked Ben about his previous experience on the 
subject. I've been able to make hefty strides toward a universal 
multi-step Undo/Redo system only to the degree that I'm writing apps 
from scratch (as opposed to porting existing code, which I used to do a 
lot of in the early days), and to the degree that those apps can be 
written with a consistent style within a consistent architecture; any 
deviance from any one of those areas would make the application design 
to broad for a single mechanism to be useful.

But sometimes constraints like that can be very valuable.  Consider MFC, 
.Net, or Apple's Cocoa.  Each of those has solid support for generalized 
Undo systems, but the ease of tapping that Undo support is relative to 
the developer's conformance to a wide range of other data management 
subsystems and structures.

There are countless ways to get similar benefits in Rev, but rather than 
attempt something as complete -- and as formal and rigid -- as a whole 
framework, I think there's a lot that can be done on a more atomic level 
in support of such efforts.

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.

There may be other specific feature requests that would be useful but 
which aren't un BZ yet.

What would be needed to see multi-level Undo implementable with relative 
ease in any Rev app?

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com