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.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
