On 7 Jun 1999, Lars R.Clausen wrote:
> You're there! Goodie, I was afraid you were away on holidays or something.
I was away for the weekend. A friend got married and i turned 25.
> > * Moving objects: The trivial part, one object moved to a new spot is
> > easy. Connections between objects complicates this a lot though. Moving
> > one object can in principle modify all objects in the diagram. The
> > variables changing here can be position, form, size, etc. These things
> > must be possible to extract from each object in an opaque data structure,
> > which can then be used to restore previous state. If a connection is
> > broken the corresponding connection object is not used. This must be
> > saved at the same address so that it can be reused later with old
> > pointers.
>
> I don't think this is that much of a problem. If we look at the situation
> right after a move is done, simply moving (with the standard move
> procedure) back to the original spot should automatically bring all
> connected objects back to their original state. Same goes for resize etc.
> If we have done other actions and then undo'ed back to this situation, we
> should still have the exact same connections, and thus a simple move will
> work again. If it was possible to break connections after an action, and
> then undo the action without undoing the breaking, then we have a much more
> complicated problem.
This might be true currently, but it places extra demands on how objects
can respond to moves. Consider the old behaviour of zigzagline (if your
remember it). It was something like this:
[]
|
|
+----+
|
|
[]
And if you moved the lower point up over the middle line it followed like
this:
[]
|
+----[]
And when you move it down again you've changed the object:
[]
|
+----+
|
|
|
[]
We can either handle this or forbid objects to have behaviour like this.
I don't think any current object has such behaviour.
> The same goes for resizing, scaling, rotating etc.
Except rounding errors, but that is probably not worth worrying about.
> > * Moving a handle:
> > This is much like moving objects. Same solution can probably be used.
> >
> > * Creating object: Pretty easy. Creating an object can connect it to
> > another though. Can this change the other object??? If this is undo:ed
> > and then redoed it must use the same memory position as before (no copy
> > tricks for undo stack) so that other redo's pointers are correct.
>
> That's a more interesting problem.
Mostly it's not a problem, as undo removes the object from the diagram,
and it can then be stored in the redo data. But does this always work?
Sometimes you might need to copy objects... I think not...
> > * Deleting objects:
> > Pretty easy. Might break connections. Can this change other objects?
> >
> > * Cut object:
> > Modifies the diagram like delete. Also modifies the clipboard. That must
> > be part of the undo-queue to.
>
> You're sure you want the clipboard modification to be part of the undo?
> Emacs, for instance, doesn't do that, and I regularly use undo-copy-redo to
> get something into the clipboard.
No, you're right. Clipboard modification can't be undo:ed. But then the
info from the clipboard must NOT be used in the apply/revert functions for
copy/cut/paste.
> > * Changing properties of an object:
> > This is a hard one. It must be possible to get and apply the 'properties'
> > data from an object. This is much like what's needed for move
> > object/handle, but this contains much more data and is used more seldom,
> > so should probably be separate call for memory reasons.
> > Maybe complete change of properties needed for multiple-object property
> > changes.
>
> Probably. The way properties are handled at the moment is not really nice,
> with each object re-implementing the dialog entries.
Yeah, we'll have to redo this.
It's not very easy to create a general dialog construction code powerfull
enought to express the class properties dialog though...
> > * Create layer:
> > Easy
> >
> > * Delete layer:
> > Needs to save possibly lots of data. Should this be undo:able?
> > Otherwise pretty easy, just store the whole layer in the undo stack.
>
> Seeing as how you can't have connections between layers (is that a bug or a
> feature? I think it's a feature:), I'd say keep the layer in the undo
> stack.
It's a feature. Makes things much cleaner and easier to handle in the
code.
> Looks fair to me.
>
> > struct Change *undo_stack; /* Points to top of stack. */
> > struct Change *current_undo; /* Points to the last Change applied */
> >
> > The first variable is used to find the first (and last) change that is
> > part of a transaction (a user-initiated change).
>
> Why not just have a last-transaction variable, and then have each
> transaction-delimiter store a link to the previous and next?
Yeah. Saves a bit of space.
> BTW, this would be a per-diagram undo, right?
Of course. All else suck.
/ Alex
