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

Here are my comments:

- Recommend using abstract class rather than interface for undo actions, 
for ease of evolution.
(For counterargument, see Item 16: "Prefer interfaces to abstract classes" 
in "Effective Java")

- Should show label for top action in label for Undo / Redo menu item (e.g 
"Undo Rename") and in toolbar button tooltip (if we have toolbar buttons 
for undo/redo).

- Having recycle bin support would allow us to undo Deletes, which would 
be nice.

- Suggest making it an IUndoService which is exposed to workbench parts 
via the IAdaptable mechanism on their site.  The undo service is 
functionality provided by the part's context, and should therefore be 
accessible via its site, not by reaching further out.  Accessing it via 
IAdaptable on the site allows us to add this service without breaking any 
APIs.  It also means parts do not encode knowledge that the undo/redo 
stack is global.  It may indeed be global, but parts should not assume 
this.  This would allow the UI to adopt different policies without 
breaking clients (maybe a per-part stack makes sense in some situations, 
as you point out in the section on multiple models). 
We would have to provide a similar way of providing services to global 
actions (actions in action sets), since they don't currently have a site 

- Other apps have the problem of consistency between Undo in the Edit menu 
and Undo in the context menu of field editors. 
Changing the undo action label appropriately helps. 
For example, in Windows Explorer:
  - create a new file foo.txt
  - rename it to bar.txt
  - go to rename it again, start typing, but don't accept the changes
  - the context menu's Undo undoes the typing
  - the Edit menu's Undo undoes the last rename
  - the Edit menu's Undo is labeled "Undo Rename"

- Regarding multiple models, in an app like Word with multiple documents, 
each document has its own undo/redo stack, and they are independent.
Unlike Eclipse, though, there is no other shared model, so they don't have 
the same problem.  You can change Word's global settings, but this is 
apparently not undoable.
In Eclipse, what should happen if you:
1. type some text in editor A
2. rename a file Foo to Bar
3. type some text in editor B
4. switch to editor A
5. choose Undo
Should it undo the typing in B?  Undo the rename?  Undo the typing in A? 
Or undo the switch (make B active again)?

Normally users don't expect navigation actions like switching editors to 
be in the undo stack (compare with Idea which does this).
The last action before the switch was typing in B, but it would be very 
rude to undo this when A is active, particularly if B is not visible 
(Notes does this BTW).

One option would be for there to be parallel stacks for each model: one 
for the workspace and one for each editor.  The stacks would be combined 
based on the current editor and the temporal order of actions.  That is, 
after step 3, the undo stack would contain undo actions for items 2 and 3, 
but not 1.  After step 4, it would contain items 1 and 2, but not 3. Users 
may find this weird though.

The other option would be to include navigation actions, in which case the 
undo stack would have items for 1,2,3 and 4.  This is at least 
explainable, but seems awkward.

It would be simpler if the workspace did not have its own stack.  Then 
there would be no overlap of models, and the histories would be clear. 
After step 3, the stack would contain only item 1.  After step 4, it would 
contain only item 3.
But this means workspace operations are not undoable, which is unfortunate 
(VS.NET does this).

I'm unsure how to solve this problem, but I feel that each editor should 
at least have its own undo stack.

Note that if we follow the service model recommended above, we can change 
the policy as to whether there's a single global stack, or one per editor, 
without breaking clients.

- I don't think it's acceptable to break existing global undo/redo action 
handlers.  We should try to make this backwards compatible if at all 
Perhaps if the action is hooked by the current part, it overrides the 
global undo stack.  Parts which maintain their own stack will still do so. 
 The global stack could still be reached by deactivating such parts.
The service model may help here too.  We could view the undo service on 
the active part's site as being the handler for the global actions unless 
the view itself hooks them.  This makes sense especially for editors if 
they maintain their own stack.
The undo service for views would delegate to the global stack.

- Should we have separate stacks per page or window?  Probably not.
The undo stacks should align with the user's notion of model.
Pages and windows are not models.  The workspace and editor contents are.

-- end --

"Randy Giffen/OTT/OTI" <Randy_Giffen@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/20/01 09:59 AM
Please respond to platform-ui-dev

        To:     platform-ui-dev@xxxxxxxxxxx
        Subject:        [platform-ui-dev] Undo/Redo Proposal

Attached are proposed changes to Undo/Redo to implement a global Undo/Redo
stack for the workbench.

Back to the top