|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 object. - 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 possible. 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 cc: 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