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

I have strong reservations against a single global undo/redo stack. There 
are many cases where this will lead to unexpected behavior when the 
effects of the action being undone are not visable (eg. simple two editor 
case when there are changes in each that are being undone) . I personally 
believe that users would expect repeated undo operations to act upon the 
active part.

Actually presenting a list of undo-able operations is problamatic and 
allowing the user to randomly choose the operations to undo is a very 
advanced feature. There are several additional problems that we would need 
to address if we unify the undo/redo stack:

        What happens when an editor/view closes

        If the undo stack is persisted when the workbench is saved what 
happens if the part contributing the action has not activated. 

        This will not work with OLE documents. They control the edit menu 
in this case. 

Instead of working on this capability I think time would be better spent 
working with the Core team to get the base level undo-redo support ,as 
well as good integration with the recycle bin. 

The other cases that are mentioned: refactoring, dealing with views, 
unwanted "free" widget behavior, integration with Core etc are interesting 
challenges. Some of which are not actually undo-redo specific requests 
some of which are covered by P1 usability items already. BTW the free 
widget behavior can be fixed. It is similiar to the "free cut/copy/paste" 
support and overriding this from the workbench is effectively the same 

So for editors, (eg. text) my preference would be for undo/redo to be 
under the control of the editor. If, for example, it uses JFace text and a 
shared document is used it would be natural and, I believe, expected that 
there would be a shared undo/redo stack associated with the underlying 
document. Otherwise the behavior would not be uniform, e.g. since edits in 
one buffer already affect other; editors undo/redo should have the same 

Question: What are the benefits of having a single global undo stack? 

I don't think we should include operations like layout changes in the 
workbench in the undo-redo stack. Giving the user the ability to reset is 

I don't think we would be able to confince existing ISV's that breaking 
their 1.0 editors was a reasonable thing to do in this case.

"Nick Edgar/OTT/OTI" <Nick_Edgar@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/23/2001 01:54 PM
Please respond to platform-ui-dev

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

I agree.  To be clear, when I say that undo/redo should be model-based, I 
mean the user model, not the implementation model.
Effective undo/redo decisions can only be made by the UI.
As an example that you mentioned earlier, if you move the text insertion 
point using the cursor, text typed after that should create a separate 
undo item, even if you positioned the cursor right after your previous 
typing, and even though the underlying document model does not "see" the 
cursor movement.

When I suggested that a document have its own undo stack (rather than the 
editor), I was assuming that it would be driven by the UI code, not the 
document itself.
If you want to keep IDocument independent of UI code (which I can 
understand), then we'll have to find some other way of associating  it 
with an undo stack.


"Kai-Uwe Maetzel/ZRH/OTI" <Kai-Uwe_Maetzel@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
11/23/01 01:41 PM
Please respond to platform-ui-dev

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

For a purely document based undo stack all neighboring document changes
look the same. Thus it either folds or does not fold them. A "good"
decision can only be made being aware of the ui. This shows again the two
aspects for undo/redo - model and ui.

                    "Nick Edgar/OTT/OTI" 
                    <Nick_Edgar@xxxxxxx>           To: 
                    Sent by:                       cc: 
                    platform-ui-dev-admin@e        Subject:     Re: 
[platform-ui-dev] Undo/Redo Proposal 
                    11/23/2001 06:08 PM 
                    Please respond to 

Another point:

We need to allow the part to modify / extend the latest undo action.
For example, if I type something, and undo action gets added.
If I continue typing, it should extend this undo action rather than adding
a new one for each character.

Note that other parts with orthogonal history may be modified in between,
and still have the same effect.
For example, if I:
  - type in editor A
  - type in editor B
  - type more in editor A,
there should only be one item for the typing in editor A.

If the other part's history is not orthogonal, it's probably simplest to
add a new item.
For example, if I:
  - type in editor A
  - rename a file
  - type more in editor A
they should be separate items if the UI presents a linear history with an
undo item for the rename.
This gets back to the problem of presenting multiple histories.
An interesting issue here is: how would the part know whether or not it
could extend the last item?


platform-ui-dev mailing list

platform-ui-dev mailing list

platform-ui-dev mailing list

Back to the top