Cytoscape Wiki|
Size: 3616
Comment:
|
Size: 5198
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 17: | Line 17: |
| January 24, 2005: "Not yet completely written" | February 1, 2005: first draft written. Needs additional detail in some areas. |
| Line 41: | Line 41: |
|
The proposed solution is to maintain multiple edit stacks, one stack per network. The Undo menu item should show the operation that is at the {{{indexOfNextAdd}}} for the network of the current network view. A keyboard accelerator operation, such as Control-Z, should execute the undo/redo operation that is at the {{{indexOfNextAdd}}} for the network of the current network view. When the user does a ''global'' edit, then distribute that edit across the different stacks, i.e. add the edit to each of the network stacks. When a ''global'' edit is undone or redone, then all of the network stacks need to be updated appropriately. This solution will require that the Undo''''''Manager be able to distinguish between a ''global'' edit and a ''local'' edit. This may require an additional argument for the Undo''''''Manager.addEdit() method. It is proposed that this argument should be a pointer to the current network, a null value indicating that the edit is ''global''. The current single argument Undo''''''Manager.addEdit() method will also be maintained, with the semantics that the edit being added is ''global''. In this way, components like the Cytoscape''''''Editor, which explicitly manage multiple network views, can specify ''local'' edits, while other components, like the Attribute''''''Browser, which do not need to manage multiple network views, can continue to use the single argument Undo''''''Manager.addEdit() method. Thus, no code changes should be necessary for components like the Attribute''''''Browser. |
|
| Line 48: | Line 52: |
| * what granuarity of operations should have undo/redo support. Certainly operations such as adding and deleting nodes and edges should be supported, but what about operations such as moving or resizing a node, or operations performed by automatic layout routines? | * what granuarity of operations should have undo/redo support. Certainly operations such as adding and deleting nodes and edges should be supported, but what about operations such as moving or resizing a node, or operations performed by automatic layout routines? |
| Line 50: | Line 54: |
| * what level of depth for undo/redo should be supported? | * what level of depth for undo/redo should be supported? |
| Line 52: | Line 56: |
| * what are the performance tradeoffs for the various undo/redo options? | * what are the performance tradeoffs for the various undo/redo options? |
RFC Name : UndoManager RFC |
Editor(s): Allan Kuchinsky |
About this document
This is an official Request for Comment (RFC) for UndoManager
For details on RFCs in general, check out the [http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments Wikipedia Entry: Request for Comments (RFCs)]
Status
February 1, 2005: first draft written. Needs additional detail in some areas.
How to Comment
To view/add comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Here is an example to get things started: ["/Comment"].
Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.
Proposal
Define and build an undo manager that handles both global edits and edits that are local to a specific network. Build a visual undo manager that shows operations so that users can select actions to undo.
Biological Questions / Use Cases
General Notes
A local edit is one that is done in the context of a single network view, such as adding a new CyNode to a CyNetwork by dragging a shape from the palette in the CytoscapeEditor. A global edit is and edit that has ramifications across multiple networks and network views, such as editing the value of a node attribute in the AttributeBrowser.
To support undo and redo, a component must remember each edit that occurs, the order of edits, and what it takes to undo and redo each edit. A component uses an instance of the UndoManager class to manage its list of undoable edits. The UndoManager manages the list by keeping a stack of undoable edits and a pointer to the indexOfNextAdd. This is described in more detail in Sun's Java tutorial at http://java.sun.com/docs/books/tutorial/uiswing/components/generaltext.html#undoableedits.
The way things are currently is that Cytoscape has an UndoManager that keeps one stack of undoable edits. Thus, if a user switches network views while going through a series of undo operations, then undo operations may be performed on networks other than the one that is currently visible. This is counter-intuitive. The undo operations should be managed on a per network view basis. This is done in tools such as Microsoft Word and PowerPoint, where undo/redo operations are managed on a per network basis.
The proposed solution is to maintain multiple edit stacks, one stack per network. The Undo menu item should show the operation that is at the indexOfNextAdd for the network of the current network view. A keyboard accelerator operation, such as Control-Z, should execute the undo/redo operation that is at the indexOfNextAdd for the network of the current network view. When the user does a global edit, then distribute that edit across the different stacks, i.e. add the edit to each of the network stacks. When a global edit is undone or redone, then all of the network stacks need to be updated appropriately.
This solution will require that the UndoManager be able to distinguish between a global edit and a local edit. This may require an additional argument for the UndoManager.addEdit() method. It is proposed that this argument should be a pointer to the current network, a null value indicating that the edit is global. The current single argument UndoManager.addEdit() method will also be maintained, with the semantics that the edit being added is global. In this way, components like the CytoscapeEditor, which explicitly manage multiple network views, can specify local edits, while other components, like the AttributeBrowser, which do not need to manage multiple network views, can continue to use the single argument UndoManager.addEdit() method. Thus, no code changes should be necessary for components like the AttributeBrowser.
Requirements
Deferred Items
Open Issues
- what granuarity of operations should have undo/redo support. Certainly operations such as adding and deleting nodes and edges should be supported, but what about operations such as moving or resizing a node, or operations performed by automatic layout routines?
- what level of depth for undo/redo should be supported?
- what are the performance tradeoffs for the various undo/redo options?
Backward Compatibility
Expected growth and plan for growth
References
Implementation Plan
- ["/Implementation Plan"]