Table Of Contents
History records user changes on a per Layer and leaf node (Graphics, etc.) basis. When attributes are altered in the inspector editor then each attribute change is recorded in a history. The history can then be viewed using the Edit menu and if desired a particular historical state can be retrieved to replace the focused graphic by clicking that history menu item or by using the undo and redo menu items.
Using the history is pretty simple but also very powerful. The following is a bullet list of some of the issues involved in the use of history.
- Off By Default: History is off by default and needs to be turned on on a per document basis.
- Focus: To scan the history of a graphic first focus on it by clicking that graphic with the mouse. Then see the History menu items in the Edit menu. To scan reordered and deleted graphics first click off all graphics (which focuses on the layer) and then use the History menu items.
- Clear: History is saved with the document and if the document is saved then consider clearing history before saving the document.
- Auto Save: If the auto save feature of a document is turned on along with history being turned on then the document is always being stored on the disk for each and every user action for which history is recorded.
- Programming: If the document is used for programming it is highly recommended that history be cleared before saving a document that is subsequently used for programming purposes (either that or keep history off). There are multiple reasons for doing that: (a) History probably does not need to transport with your custom application, (b) It reduces the size of an app, (c) it speeds processing and (d) if recursion is utilized along with previously reordered graphics then the algorithms that parse history state can be prone to malfunctioning. Every attempt has been made to optimize history parsing, however each new feature adds overhead and complexity. If a document is loaded into a Custom Application then part of the load process clears the history before the document is used.
- Controls: Some controls, such as a dial or text field, need focus and those controls have their own history or undo and redo mechanisms. In order to undo a graphic after an inspector editor change the graphic may first need to be clicked on to reestablish history focus.
- Not Document Wide: There is no paradigm for recording user events that work in all situations and multiple paradigms may be appropriate for a particular situation. Typically undo and redo operations can span many elements of a document and it is hard to determine what will happen if the undo (stack) is invoked because (unlike keyboard focus with a focus ring) there is no context for the undo operation save document-wide context. In Graph IDE the history context is on a per graphic and layer basis within a single graphic view. That may be somewhat atypical but is the desired implementation (having considered various implementations for years (decades)).