As I see it, such a Morph would be connected to two (or more?) Morphs and would maintain some kind of spatial constraint between the points at which it was connected. A simple version would make sure that the two attached Morphs were attached at the same point.
Is this related to Fabrik? Could the connectors in a Fabrik like system could use AttachmentMorphs for implementing connections.
It would be interesting to see if the constraints could be made pluggable such that new and interesting things (things akin to Fabrik for example) could be done with AttachmentMorphs.
Would the constraint behavior be best in a different class whose instances are used by AttachmentMorphs?
- Stephen
Stephen Pair wrote:
Is this related to Fabrik? Could the connectors in a Fabrik like system could use AttachmentMorphs for implementing connections.
Dan could say more about Fabrik, but at least from the graphical end of things, these could implement the visual connections. A subclass could add more refinement (like providing for dataflow).
It would be interesting to see if the constraints could be made pluggable such that new and interesting things (things akin to Fabrik for example) could be done with AttachmentMorphs.
That would be interesting. I'm a bit frustrated with pluggability (using blocks) right now in Squeak, having made a nice FSM package that worked fine in VW, but failed horribly in Squeak because of its lack of BlockClosures (hint: a BlockContext cannot be executed more than once at a time). It used blocks for its configuration.
So in Squeak, we'd either have to copy blocks, or use objects to plug with.
Would the constraint behavior be best in a different class whose instances are used by AttachmentMorphs?
Yes, probably. These could be called upon Morph>>step, as well as during mouse dragging/up/down, and could do whatever they needed to.
squeak-dev@lists.squeakfoundation.org