On 19/12/2012 10:22, Александр С. wrote:
What about this architecture:
The new system replaces the old (for the code editor) and contains
functions for the form designer. Snapshot is composed of code and
form, snapshot is retained after each action in the code editor or in
the form designer. Snapshots are stored in an array, which will
compressed. Undo-action: snapshot is taken from a array and replaces
the current form and code.
One undo-list will be for the two editors in the result.
Integrating the editors undo, will be a later step. When it is done, I
am pretty sure SynEdis undo system can be extended, to store some extra
info, and trigger callbacks.
The editing and the designing were never 100% in Sync. Undo the
"Button1: TButton" in the editor is just one way of breaking thigs. The
user can edit/remove this code outside undo events. Fully fixing this
(if desired at all) is possible, but not part of designer undo project.
For the designer undo, it will only be of interest, to act, if the user
undoes such code.
Therefore most other undo events in the editor, are not of interest.
It is enough, if the designer can register a callback for selected undos
with the editor.
There are 2 ways an interaction can happen:
** 1) undo in the designer:
Code in the editor is added or removed like on any designer action.
Example:
- user creates TButton ( "Button1: TButton" is added to editor)
Designer: has a TButton-add-undo
Editor: has an insert-text-undo (with a callback to designer
- user edits other text, more undo in editor
Now the editor can not perform the above undo, unless all the
editing is undone as well (undo can currently only be done in exact
reverse order)
- user does UNDO in designer
Designer: executes TButton-add-undo / creates a redo action
this will remove the declaration from the editor, much the same way
like a normal delete component.
Editor: ADD another undo "text-deleted-undo" (with callback to designer)
This is another edit action, with a new undo info
So after that, in the editor, you have 2 undos from designer actions.
If you undo in the editor, the designer executes the redo, and adds the
button again
This may seem slightly illogical. But the alternatives are
- A - One undo list, with strict order for all actions from editor and
designer: You can not undo in the designer, until you undid all the
text=changes that you did imbetween. That is a huge restriction.
AND that has another problem: The designer interacts with several
editors: the undo lists of ALL editors would need to be synced. Undo in
file Foo would start being dependent on undo in file Bar....
- B - Allow to execute undo in random order. That is allow to undo
selective items, from any position of the undo stack, not just top. That
is possible of course. But it is a huge task of it's own.
If indeed agreed on: It would have to be done before the designer undo.
I would not suggest to this as part of the designer undo.
(B) can still be done later, If the callback system is implemented now,
then it will be easy to change. B would still use the callbacks. But if
the designer does an undo, instead of triggering an edit to the editor
(creating a new edit-undo) it would tell the editor, to go and find and
remove the selected undo item.
The fact that it can be changed this way later, shows that this is an
editor issue, not part of the designer undo.
** 2) undo in the editor:
works as always, but informs the designer on events created by the designer
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
