## page was renamed from RFCTemplate ## This template may be useful for creating new RFC's (Request for comments) ## This is a wiki comment - leave these in so that people can see them when editing the page || '''RFC Name''' : UndoManager RFC || '''Editor(s)''': Allan Kuchinsky|| <> == About this document == This is an official Request for Comment (RFC) for the Cytoscape undo manager. 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. Maintain one edit stack per network. Distribute ''global'' edits to all network stacks. == 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 Cy''''''Node to a Cy''''''Network by dragging a shape from the palette in the Cytoscape''''''Editor. 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 Attribute''''''Browser. 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 Undo''''''Manager class to manage its list of undoable edits. The Undo''''''Manager 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 Undo''''''Manager 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 Power''''''Point, where undo/redo operations are managed on a per network basis. One potential solution is to maintain multiple edit stacks, one stack per network. The Undo menu item would show the operation that is at the {{{indexOfNextAdd}}} for the network of the current network view. A keyboard accelerator operation, such as Control-Z, would 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 would 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. This argument could be a pointer to the current network, a null value indicating that the edit is ''global''. The current single argument Undo''''''Manager.addEdit() method would 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, could continue to use the single argument Undo''''''Manager.addEdit() method. Thus, no code changes would be necessary for components like the Attribute''''''Browser. An alternative approach, which is more restrictive to the user but also less complicated, would be to keep just one edit stack and clear it when the network view is changed. This is the model in Microsoft Outlook. If you make changes in the Mail view and then switch to Calendar view, the edit stack is cleared. If you return to the Mail view you won't be able to undo any prior operations. This approach would keep the basic functionality of the current Cytoscape UndoManager pretty much unchanged -- the only addition needed would be a listener that cleared the edit stack upon NETWORK_VIEW_FOCUSED events. ''Question: How restrictive is this for the average user? How often will the typical user be switching between network views and desiring a multi-level undo at the same time?'' == Requirements == == Deferred Items == == Open Issues == * Is the current event firing regimen sufficient for driving the management of multiple networks? For example, when an edit is undone or redone, can the undo or redo method be relied upon to fire the appropriate event when a node or edge is added or deleted? * 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]]