danielv@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).
squeak-dev@lists.squeakfoundation.org