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: Brock Brandenberg <email@hidden>
- Date: Wed, 29 Jan 2003 14:23:06 -0600
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.
So, some of the time it's not about being faster or taking less memory to do
it by snapshot rather than undo invocation, but rather about it being the
only way to achieve the undo :)
Brock Brandenberg
>
> Another issue is calculations. Not everything can be undone by
>
> actions! Imagine I have an object graph on which I need to perform a
>
> calculation. Lots of attributes get changed and then I need to undo. I
>
> can't register the contrary of an optimisation calculation (imagine I
>
> am optimising a schedule for example). The only way here would be to
>
> duplicate the whole object graph and upon an undo discard the new
>
> object graph.
>
>
What you should be doing here is registering an undo invocation for
>
every individual attribute change. All of those attribute changes end
>
up in the same undo group (which is the whole reason why undo groups
>
exist). At the action level you just set the name to "Optimisation
>
Calculation" or whatever.
>
>
Voila, when you look at the Edit menu it shows "Undo Optimisation
>
Calculation", and when you hit cmd-z, all of those attribute changes
>
are set back to their original values. (And of course you _are_ using
>
notifications or some other method to redraw your view when the
>
attributes change rather than making your control or view layer redraw
>
itself, right? Otherwise, not only is undo/redo going to be more
>
difficult to get right, but you won't be able to implement AppleScript
>
support easily either.)
>
>
Now there may well be rare times when you are changing so much of your
>
model that storing a whole snapshot of the object graph is smaller and
>
faster than generating the big series of attribute changes. But this is
>
an optimization that you shouldn't worry about unless you profile your
>
app and find that it is an issue.
----- industrial design @ www.bergdesign.com ------
_______________________________________________
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.