Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Undo/Redo Proposal

Attached is the proposal containing my comments.

Simon :-)


(See attached file: undo_redo.html)
Title: Undo Redo Proposal

Undo Redo Proposal

Topic: Undo Redo support in the Eclipse workbench
Created: 15 Nov 2001 by Randy Giffen
Modified:  20 Nov 2001 by Randy with comments from Dirk

[SA: My comments below]


Currently, the Eclipse workbench includes global actions for Undo and Redo. They appear as the first two items in the edit menu. As global actions, they are targeted to the current active part in the current perspective. If the active part does not supply a global action handler for them, they are disabled. This means that the action that will be performed by Undo or Redo is dependent on the active part and thus the behavior of these actions is modal. In many cases the user must go back to the appropriate part before being able to undo an action performed there.

The Details


Global actions are actions defined by the Eclipse workbench UI which delegate their enablement and action to a global action handler supplied but the active workbench part. Global actions were introduced to provide a degree of consistency in the UI. The idea was that common functions like undo/redo, cut/copy/paste, and delete should have a consistent location in the UI and consistent menu accelerators. An additional benefit is that views (which cannot contribute to the window menu and thus cannot define menu accelerators) are able to respond to the menu accelerators defined for global actions.

Thus, in a way, the name global is a bit misleading in the undo/redo case. The actions do not support a global undo/redo stack. They support a targeted undo/redo directed at, and implemented by, the active part. This is typically not what most users expect. In the case of an IDE, they are using the UI to manipulate (make changes to) a model. They expect that undo/redo will allow them to back out of or redo these changes regardless of what part of the ui they are currently working.

This architecture requires that parts maintain their own undo/redo stack (although theoretically some parts may decide to implement a shred stack among themselves).

Another problem is that actions that don't belong to a view (e.g. like the "Refactor" menu which gets retargeted to the active view) can't access the undo/redo actions in the edit menu.

Possible Options

Let us assume for the moment that a workbench undo/redo stack is a good idea and consider its implementation (this is based on discussions and PR 1887). We would define an IUndoManager and add a method to IWorkbench to obtain such a manger. The manager would have api for adding and removing a IUndoActions from the manager.

[SA: I believe the undo/redo manager is at a too high level on IWorkbench. It should be on a IWorkbenchPage level instead. For example, let say you open two "type hierarchy perspectives" in separate page (whether these pages are in separate windows or both in the same window matters not), you make some changes in the 1st page, then switch to the 2nd page. A user would not expect to be able to undo changes done in the 1st page from the 2nd page - the user would not even be able to see these changes as they are undone.]

[SA: How about the interface name IChangeManager instead of IUndoManager and IChangeRecord instead of IUndoAction. Having the word "Action" is misleading to me.]

IUndoAction would have the following definition

public interface IUndoAction {
 String getLabel();
 void undo();
 void redo();
 boolean isUndoValid();
 boolean isRedoValid();
 void dispose();

Comment: Should we consider having an abstract UndoAction rather than an IUndoAction? In some cases this would allow us to modify API in a non-breaking way but it means that clients will not be able to use an existing type to implement IUndoAction (probably a rare case).

[SA: Leave it as an interface. Of the method listed above, I see none of them that the abstract class could provide a default implementation. However, just like we do with other interfaces, it might be nice to provide an abstract class in addition to the interface if it can provide useful helper methods...we'll know this when we start implementing undo/redo for our views and editors.]

The manager will ensure that the top undo action and top redo action are valid by calling the isUndoValid() and isRedoValid() api methods. If the undo/redo action is no longer valid it will be punted and the next one moved to the top.

[SA: Do other applications do this (e.g. remove changes on that stack that cannot be undone/redone)? I wonder if the user will be surprised that something was skipped when hitting undo? Maybe not. I would assume the typical user can probably only remember the last 2-3 changes anyway. Something to check with the usuability guys maybe?]

The valid check is required as an undo action cannot validate itself simply by listening to model changes. It would also somehow need additional information if the received delta will have an undo which will be put onto the undo stack. Consider the following case: A Java refactoring renames file to Then the user goes to the navigator and renames to C.txt. If the navigator pushes an undo action onto the stack, the refactoring undo is still valid since the user must first perform the undo for "rename to C.txt" before he can execute the undo for "rename to". If the refactoring kernel listened to model changes only, without knowing that there is an undo for the renaming of to C.txt, the kernel would invalidate the undo for rename to

Note that we are only going to validate the top undo/redo actions. Validating others on the stack would be too complicated. Consider the case where one renames a compilation unit. In this case we have two changes, one that renames the top level type and one that actual renames the file. To be able to figure out if the undo for this refactoring is still valid, we have to check if both changes are still valid. To do so we have to simulate the undo of the rename of the file to be able to check if we still can undo the renaming of the top level type. This is necessary since the rename of the top level type doesn't know anything about the rename of the file. For example:

Rename to

  1. change top level type in file to B. The undo is change top level type in file to A
  2. change filename from to The undo is change to
To figure out if this refactoring can still be undone we have to simulate the rename form to Otherwise we can't check the undo "change top level type in file to A" since doesn't exist.

We would add tool bar buttons for undo and redo with a menu button to the right like the "new" button. The menu button would show the current undo or redo stack and let you select at any level in the stack. Again it is important that IUndoActions be able to validate themselves since this will determine the enablement of these buttons. The undo and redo actions in the Edit menu would show the label for the action currently at the top of their stacks.

[SA: I find the undo/redo stack list an advanced user option. It should not be visible by default. Most apps to not provide such a list (I usually only see this lsit in graphic software). If we provide the list, how does it work? If I select in the middle of the list does it mean undo everything on the stack unto the one I selected? Or simply undo the one selected? You mentionned above that only the top undo action will be validated - how can you populate the list if you do not know if the other undo actions are valid?]

Once the new api is available, it is likely than many more actions would become undoable (ex. resource rename, move etc.).

Problems with a Global Undo/Redo Stack

1) Since undo and redo are part of the IWorkbenchActionConstants.GLOBAL_ACTIONS, it would be a breaking API change to no longer support undo and redo as global (retargetable) actions. Parts that are currently maintaining their own undo/redo stack would have to change to add IUndoActions to the workbench stack. Until then the Edit menu actions and their accelerators would no longer trigger an action in the part. This is probably an acceptable breaking change.

[SA: If the only way to keep things consistent for the user requires that the API be broken, so be it. However, if there is a way to be somewhat backward compatible without confusing the user, then bonus! Focus on what is best for the user, not the plug-in developer.]

2) The text widget implements its own undo. For example create a new task and edit its description note that there is an undo item in the widgets popup menu. This undo is local to the widget. Currently Undo is not enabled under edit in this case since the tasklist does not supply a global action handler for this purpose (There is no api on Text to allow programmatic undo). However if we have a global stack it is likely that Edit>Undo would be enabled but it would perform something different than undo on the popup.
Thus should we:
    1) We could ask SWT for undo API on text in this case.
    2) Continue to allow Undo/Redo to be global actions for which we simply define a default behavior (which will not be retargeted by 95% of the parts).

[SA: I'm not sure what the second point means...could you provide more details?]

3) It is not clear that an IDE built using the workbench has only a single model. For example, suppose I
i) Edit some .java file in the Java perspective
ii) Switch to the Team perspective and create something in the Repositories view
iii) Switch back to the Java perspective, decide I don't like my change and press Undo.
A global stack will cause the item I created in the team perspective to be removed (this will perhaps happen silently).
But this is exactly what some would expect. They find it confusing to have more than one undo stack in an application.

[SA: See my first comment about this. The user will be focus on a workbench page and therefore will want the undo/redo to be limited to that page (even more so now with the work being done for the lost of context problems)]

4) How do we define what can go on the undo redo stack? Do we limit it to model changes? For example opening an editor could have an undo that would allow the user to close the editor and return to the previously active part.

[SA: Most undo/redo I've worked with stick to model changes only. We'll need to write some guidelines - there is a guideline doc being written as part of  the lost of context work that it should go into.]

Back to the top