introduction. MlView has an infinite undo/redo feature designed around the concept of "document mutation". A document mutation is basically the abstraction of a modification of the document model. From now on, we will refer to changes on the document model as "document mutations".

Design of the Undo infrastructure. The Undo feature lives at the MlViewXMLDocument level. This class is the document object model used by MlView. It has methods like MlViewXMLDocument::add_child_node() that actually perform mutations on the document. Each time a mutation is performed on an instance of MlViewXMLDocument, a mutation is "stored" in an undo stack. Each MlViewXMLDocument has a private instance of undo stack. The undo stack is an instance of MlViewDocMutationStack. It is a stack of instances of MlViewDocMutation. At instanciation time MlViewDocMutation object must be registered callbacks that will be called to do or undo the mutation. Later on, the client code can invoke MlViewDocMutation::do_mutation() or MlViewDocMutation::undo_mutation() to do/undo a given mutation. As I said earlier, each time a mutation occurs, an instance of MlViewDocMutation that matches that mutation is pushed on the undo stack. Later on, the MlViewXMLDocument::undo_mutation() method (that execute the undo feature) pops the topmost instance of MlViewDocMutation from the undo stack and invokes its MlViewDocMutation::undo_mutation() method. That MlViewDocMutation::undo_mutation() method calls the undo code registered by the client code to actually perform the undo. Simple isn't it ? ;)

Then comes the Redo ... To be continued ...