Community
Participate
Working Groups
The Undo and Redo actions in the desktop currently target the active part. This means that (a) if you perform action X in part X and switch to part Y you can no longer undo action X. This is inconsistent with most undo implementations. (b) each part is forced to implement an undo stack. I think undo / redo should be performed on a temporal basis, ie, you undo the last action, regardless of the current active part. To support this the desktop should hold and expose an an undo stack. Actions which are undoable should register with the stack to be included in the undo redo support. If we look at the Patterns book the action defines an execute and unexecute method. Following this pattern, the IAction interface in jface would change. If this is not appropriate perhaps the desktop could define an interface called IUndoAction which has an interface similar to the following .. public interface IUndoAction { String getLabel(); void undo(); void redo(); void dispose(); } I suspect that an IUndoAction implementor would contain a handle to the action target, the action attributes, and any undo state required. NOTES:
I agree that this may make sense when switching between views and an editor. But what about the case of switching between editors. If I manke a change to A.txt and then to B.txt and then go back to A.txt, I would not expect undo to undo the change to B.txt (which would be hidden). I expect the undo action to undo the last change of the editor I am working in.
Post 2.0
Reopened for investigation. The most recent discussion of undo involved adding an undo service to sites. The service would be associated with an id (by default the site id). Thus a particular service could be assessed form any site. For example an action performed in the packages view could add an item to the current editor's undo service.
No plans for this in 2.1 release.
Just making sure someone is listening to this bug.
Different models should have their own undo/redo stacks. So editors for A.txt and B.txt would have their own stacks, but if A.txt was open in two editors (e.g. in different windows), then they would share the stack.
Susan: I believe this is your area of expertise now. :)
The undoable operation framework introduced in M5 allows the part to choose what should happen. A part can use the supplied undo and redo action handlers to filter the undo history based on an "undo context." Text editors will likely keep their own localized context, with some interest in more global operations that affect them (like a refactoring operation on their model). Workspace-wide operations occur in a "workspace undo context" and any part that uses this as its undo context (such as the navigator) will have more "temporal" undo. This bug will be kept open until refactoring and text are integrated with the new framework (target M6) and we work through the scenarios. There is more discussion of this topic in bug #37716 and in the undo proposal for 3.1 at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui- home/R3_1/undo-redo-proposal/undo-redo%20support.html
moving milestone target to M7. Text undo is released and operational. Refactoring undo adaptation is released but not yet enabled. This will occur during M7.
This bug (and its related plan items (bug #37716, bug #80137) are now fixed. Any specific issues with the implementation of the framework should be opened as individual bug reports.
Verified in I20050509-2010 by running manual tests (org.eclipse.ui.tests/Manual Component Tests/undo.txt)
