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.
• Registration of a filter proxy and setting of its input must be part of the same UndoSet. This is required since on undo/redo, all modified proxies are updated. If a proxy that requires an input gets created in a redo action and its input was not set then when the ProxyManager updates all proxies, we will get errors. This is overcome by making sure that setting input and registration are part of the same undo set. Re-setting the input later is perfecly fine (ofcourse if the filter supports it.)