danielv at netvision.net.il wrote:

> > The motion of the attached Morph would be done via a callback to the morph,
> > so it could do something appropriate. The default would be to move the entire
> > Morph.
> Other possible behaviors -
> Nothing (like you connection morphs)
> Resizing (like when you pull a resize handle)
> Shared resizing (like panes in a system window thats being resized)

Yes, I can see this strategy being different for each end of the attachment.
Attaching a line to a rectangle, for instance, we probably don't want the
rectangle to move when you try to move the line, but we do want the line
endpoint to move when the rectangle is moved.

> I think i would want to first do all the connections, and then be able
> to play with how each morph reacts to each connection. So it should be
> easy to see (in edit mode?) what each connection behaves like, and
> modify it without reattaching manually. Implementation idea - using a
> state/strategy pattern (the attachment morph delegates decisions to a
> policy object it holds, which can be replaced at runtime) for the
> attachment morph might help doing this.

I like this idea. This is yet another case, though, where there are
lots of options, which will probably appear on a menu (out of laziness).

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com