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 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

Back to the top