Undo Implementation

Overview

This page describes the Undo/Redo framework as it is currently (Apr 13, 2006) implemented. This is based on Undo Design.

API

Core

• vtkUndoElement represents a vtkStateContainer described in Undo Design. The change is that vtkUndoElement supports an Undo as well as a Redo action. Thus, every vtkUndoElement can undo as well as redo itself.
• vtkUndoSet represents a vtkStateChangeSet described in Undo Design. The change is that it maintains a single list of elements instead of separate collections for Undo and Redo. The elements are expected to be added in the sequence of execution, thus when Undoing, the elements are undone in reverse order of which they were added and when Redoing the elemens are redone in the order they were added to the set.
• vtkUndoStack is similar to what described in the design documents.

Server Manager

• vtkSMUndoStack encapsulates the undo/redo stack for the server manager.
• The undo/redo stack for server manager changes is maintained on the data server for every connection. Thus when every any client pushes any undo set on the stack, it is sent to the server. On undo/redo the undo set is fetched from the server and appropriate operation is performed.
• vtkSMUndoStack can be used to record the changes to server manager and create undo sets. To begin recording such changes, use BeginUndoSet and terminate with EndUndoSet. On EndUndoSet the undo set generated is pushed onto the server's stack. Since every connection has its own server, it is necessary that changes to proxies on different connections are grouped in separate Begin/EndUndoSet actions.
• The undo set state is pushed on the server as XML. When this state is fetched on the client for undo or redo, the xml is parsed to generate a vtkUndoSet object using a vtkSMUndoRedoStateLoader. GUI can subclass this to process GUI specific xml elements.
• vtkSMUndoStack keeps track of the order in which different connections were accessed, so to undo/redo, one just call Undo()/Redo() without worrying about connections.

Note

• Every proxy/compound proxy involved must be registered with the Proxy Manager. Also the registration must be captured in an UndoSet. This will make sure that the proxies are created when redoing (if they get deleted while undoing) or vice versa.
• Accept has to happen one connection at a time. Another approach would be to keep separate vtkSMUndoStacks for each connection. The latter is not supported right now on the ServerManager.
• Before any undoable changes are pushed to SM properties (ie. when before setting values on vtkSMProperties: not to confuse with pushing values to server i.e. UpdateVTKObjects), vtkSMUndoStack::BeginUndoSet() must be called. On finishing with setting of the values, vtkSMUndoStack::EndUndoSet() must be called.
• Registering of a display proxy, setting up of display input connection and adding of the display to the RenderModule has to be captured in an undo set, preferably the source proxy registration undo set. That way, when one undo's a source proxy creation, the display will also get cleaned up properly. This is the reason why currently undo/redoing creation of a filter/source does not work.