On Tue, 8 Jun 1999, [EMAIL PROTECTED] wrote:
> 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.
Ah, congratulations.
>> > * 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:
>
> []
> |
> +----+
> |
> |
> |
> []
You mean:
[]
|
|
|
|
+----[]
It still does that -- the extra bend disappears.
> We can either handle this or forbid objects to have behaviour like this.
> I don't think any current object has such behaviour.
Think again... interestingly, when you move it by connecting it to
something else and moving that, the extra bends don't disappear. Possibly
the addition/removal of the bends should be in undo, too.
>> The same goes for resizing, scaling, rotating etc.
>
> Except rounding errors, but that is probably not worth worrying about.
Probably not.
>> > * 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...
We will clear all redo data when something other than undo/redo is done,
right?
Then I don't see any problems in keeping it there.
>> 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.
Right, those should be 'insert/delete' operations, and copy wouldn't have
any undo effect.
>> > * 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...
I see the problem... I thought about making the dialogs with macros. Not
that nice, but a possibility. Then the specialized dialogs can be done 'by
hand'.
>> BTW, this would be a per-diagram undo, right?
>
> Of course. All else suck.
Well, property dialogs are global. Should they be that? (Not that it's
entirely related, I was just wondering.)
-Lars
--
Lars R. Clausen (http://shasta.cs.uiuc.edu/~lrclause) Hårdgrim of Westfield
"I do not agree with a word that you say, but I will defend to the death your
right to say it." -- Voltaire (?)
