Re: Action based undo or snapshot based undo?
Re: Action based undo or snapshot based undo?
- Subject: Re: Action based undo or snapshot based undo?
- From: Greg Titus <email@hidden>
- Date: Wed, 29 Jan 2003 18:56:54 -0800
On Wednesday, January 29, 2003, at 12:23 PM, Brock Brandenberg wrote:
While I don't have a solution for this problem, I too am affected by
it like
Alexander, and would like to see how others handle the issue.
What Greg mentions is possible much of the time, but it is simply not
possible to do in some situations like Alexander mentions. Many
mathematical
problems, like optimization problems, simply do not have an inverse and
cannot be undone by registering undo invocations for every attribute
change.
The process may simply not be reversible, no matter how much one
thinks that
you can reverse each and every attribute change. Destructive and
non-reversible actions can occur during an optimization that are not
captured by the state of the objects, and hence, cannot be undone by
simply
invoking attribute changes in a reverse order.
Could you give an example of this difficulty?
I posit that any action which should be undoable results in one or more
attribute changes in the state of your model objects. If something is
destructive and non-reversible it is because you are not adding an undo
action when you should, or parts of your application 'state' are not
captured by the state of the model objects, which means you haven't
designed your model correctly.
"Optimization problems" is a pretty wide field, so obviously I have to
be very vague, but optimizing means finding the values of the variables
in the system that maximize (or minimize) some mathematical function,
given some constraints. It seems fairly straightforward to me to make
the variables be your model objects, and register an undo whenever one
of their values changes. Optimizing for some function and set of
constraints, then, results in zero or more changes to the values of the
variables, all of which are reversible, and thus undoable.
I'm currently working on OmniGraffle, a diagramming and graph layout
application. It includes a force-directed layout action, which uses
simulated annealing to position graph nodes based upon constraints
given by the edges of the canvas and the lines between the nodes (as
well as other constraints). This is a classic mathematical optimization
problem, simulated annealing is a well-known approach, and it is
obviously a non-reversible algorithm. But we have absolutely no issue
with being able to undo a layout action, because it just decomposes
into many, many position changes on individual nodes, all of which are
trivially reversible and undoable.
I'd very much like to understand the cases in which this kind of
solution are not possible.
Thanks,
- Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.