[Protux-devel] (no subject)

[Luciano Giordana]

This is to put some guidelines on UNDO engine specification/implementation.
The discussion on this subject, so far, was not deep, so I suggest that this
works as a restart for this matter.

On previous discussion, we put some of the modern theories on undo, which
is, as most you might know, something pretty complex to code.
There are some approaches which we could be fit protux in, but I selected
two that compreehends the others, someway.

They are the "memory image" approach, and the "action/anti-action" approach.


1) The Memory Image approach.

On many application, being or not an Audio Application, we frequently see a
master file that represent the project you are
workin in. A Simple (and dumb) undo engine, will just keep a list of
previous copies of this file, and , when "undoing", it restores
back a specific copy so the project get back into a previous state. This
approach is pretty simple to implement, but brings 2 main problems :

- The performance : For a huge project, restoring such a complex data
structures as protux have (peaks, audio lists, clip lists, and many others)
is quite hard to do. That would demand maybe seconds of CPU time to destroy
all current strutures, reconstruct them and
re-reference them, using the same references used in the before-undo state.

- Lack of usability. Sometimes, you dont want to undo ALL the stuff, just
part of it. Suppse you applied a filter on a clip and
re-rendered the project. Then you decide to "undo". First the whole rendered
project would be discarded, and just after that, the filter
you applied will be undone. This is dumb, since most of your rendered
project was not affected by that filter.

- Every single action must resave the entire project, which can be huge
operation in some projects.

Althoug we can easly see that "memory image" technique is not a good
solution, this approach has some advantages :

- Pretty stable and rarely fails.
- Easy to implement
- persistent (even if you quit appliction, you will be able to undo last
change when re-opening it)

2) The action/anti-action approach


In the action/anti-action paradigm, every single action has an anti-action
assigned to it, bringing data structures that holds
all data involved on that action. When undoing, another "ACTION" is
performed, but this time, that "ACTION" has the oposite effect from the
original one.
For example : suppose you delete a clip. If you undo, a "new clip" is
inserted, with the same caracteristics from the previous one.

The problems here are many, but some of them are "potential problems", so a
good implementation might avoid them. Most important are :

- hard to card, since it required many data structures and conditionals
- Requires a super class that is inherited by all other classes, since they
will share common abstract methods
- Requires a stack to hold data in case of antiaction must restore data
deleted by action
- not persistent (once you quit appliction, you will not be able to undo
last change  when re-opening it)

The advantages

- (much) Better performance
- More context-specific undos.
- Possibility to undo not-only-last actions
- low memory consumption


This initial text aims to give a initial sight of what have been discussing
so far. We should improve this discussion soon since
basic infrastructure is about to be coded. so, RFC on this :-) please.

Luciano


________________________________________________
Horizon Serviços Digitais
Assine já! - 0300 789 70 90