[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Undo/Redo Proposal
|
Interesting reading.
Here some comments to a few aspects of the discussion.
- Undo/redo is task centric. Meaning that it has model aspects as well as
ui aspects. Consider a document based text editor. User interactions are
translated into document changes. When a user wants to roll back the most
recent changes than this should happened in the portions reflecting the way
in which they were applied. E.g. a user types "rudi " and then scrolls up
to look something, uses hover help, etc., - all without moving the cursor.
Then the user continues typing "ratlos". Having done this, the user decides
to undo the change. My expectation is that the user has to preform undo two
times to remove what has been typed because it reflects what and how the
user did it. If the user performs a refactoring which should be rolled back
afterwards, I expect it to happen in one step as the refactoring UI is a
modal wizard. So the perception of refactoring is that of a one step
operation. Thus for me the question is not model or ui. It's both and the
concrete shape of undo predominately depends on how the UI is designed with
which the changes are made. Consequently, an architecture has to support
those two aspects.
- Undo/redo is task centric and usually tasks are nested. If the user
creates a file, edits the file, saves the file, there should be two undo
stacks be involved. The resource based one and the text based one. While
editing the file, the editor only deals with the text based one, on save a
new item is pushed onto the resource based one. Whether the editor does
this explicitly depends upon the undo awareness of the underlying
infrastructure. I.e. if IFile.save(...) updates the resource based undo
stack, the editor is not required to do it. Nesting of tasks appears
everywhere where an edit/commit model is used. Reflecting the structure of
task would imply something like chained undo/redo stacks.
- A task can involve multiple steps, each of them performed in another ui
part. For example think of multi page editors or just on Nick's argument
about shared editors. Thus, take the previous example and consider the fact
where the file is edited in multiple editors at the same time. Then we have
chained undo stacks where undo stacks are shared between several
components. In order to be general enough the architecture must not limit
the sharing of undo stacks to editors, or documents, or whatsoever.
- The points above taken, I think undo/redo cannot be limited to the ui.
The concept of undo/redo stacks, etc. should become part of the core.
- I strongly support a ui independent text infrastructure. No surprise, I
have been pushing for this for 18 months now. It just takes it time.
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 04:50 PM
Please respond to
platform-ui-dev
Some further comments:
In my earlier comments, I suggested that each editor have its own undo
history.
I'm not sure I believe this anymore. While I believe that a single global
history is not the right answer, it's not clear that an editor should have
its own history.
If undo/redo should be model-centric, then it makes more sense for the
document to have its own undo history, not the editor.
We currently allow the same file (document) to be open in multiple editors
(i.e. in a different page or window).
Changes applied in one are visible in the other. It therefore feels that
actions done in one should be undoable in the other.
Unfortunately, the workbench itself has no general notion of a document or
buffer. The current document sharing is defined by JFace Text (and is
supported at the Eclipse UI level).
This lack of a general document model poses a problem in other areas too.
For example, we were considering having a limited number of editor tabs,
but still having the open documents available via another dialog, much
like Emacs does. We can't currently do this in general, just for text.
At first I thought it might make sense to allow a part to create its own
history. In this case, the text editor would create a new history for the
document, if it didn't already have one.
But we haven't solved the problem of multiple histories yet, even in the
restricted case of one global history plus one history per editor.
So I wouldn't recommend this approach currently <g>.
For now, we could provide the undo service to parts, and manage a separate
history per editor.
This is what people will want if they do their own nontextual editors,
unless they also have their own shared document model.
If we later come up with a generic shared document model, then we can
provide an undo service to the document.
We could do this now for text documents. We just need to ensure that the
document's undo service doesn't conflict with the editor's.
This could require asking the undo service to activate itself, rather than
assuming it's always active.
In the case of text editors, the editor's undo service would not be
activated, but the document's service would be.
Nick
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
