Re: [platform-ui-dev] Undo/Redo Proposal

["Nick Edgar/OTT/OTI" <Nick_Edgar@xxxxxxx>]

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.

Nick





"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
        cc: 
        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.
Kai



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



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?

Nick

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev




_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev