[
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
problem.
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
rules.
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
sufficient.
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
cc:
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.
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
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
