Moved to moose-dev...

Alexandre Bergel wrote:
Alexandre,  I think this example shows what I was badly hinting at with my "ROElement>>mostSpecificParentCommonWith:" thread.  This used to decide which level within a hierarchy of sub-element edges are stored.  Referring to the first attachement of Cipirian's post "Figure 2(a)", I think in this case the "inner" edges should be stored as part of the "Composite" element, but I think currently they would be stored in the parent of "Composite".
    

if you check the sender of #mostSpecificParentCommonWith: then you will see that only the Mondrian builder makes use of it. Currently, and outside the Mondrian DSL, you can insert the edge where you actually want, independently of its extremities.

  
Also I had been thinking for a while that it would be nice to be able to have AttachPoints rendered - both as permanently-visible and also visible-on-hover-only, so that when I re-implement the edge rubber-banding to interactive draw lines between elements (which I demoed to you a while ago on Mondrian) the user could drop the edge-end onto a specific AttachPoint.
    

This should be easy to do. 
However before to work on this, I have a question about what Roassal currently offers.
In Roassal, lines knows about the attach points, i.e., the class ROLine has a variable called 'attachPoint', intended to hold an instance of ROAttachPoint. It is therefore not the node the is aware of it. It is more flexible in my opinion than what traditional drawing tools offers.

I am wondering whether this is what we really want. Shouldn't the element/node be aware of its attachpoint, instead of its edges?

Cheers,
Alexandre

  
(Without any hard experience to back this) I would think that Elements more than Edges need to know about attachPoints.   Edges holds links to the 'from' and 'to' nodes, so can easily get to them that way anyway.  Elements don't hold edges so the reverse direction is harder. 

btw, when I was experimenting with the ortho shapes for edges and ROAttachPoint for the first time, my immediate reaction was that this was individual instance of a point-of-attachment.  The way the current implementation actually returns a collection of Points I feel is more like a ROAttachPointStrategy.  I was wondering if the Element should hold individual point-of-attachments - for instance if a connecting edge wants "the next unused attachPoint - or if an attachPoint would look different if more than one edge was connected (like splay out a small bit) - but then I don't know if that is the sort of caching that you've indicated in the past can cause problems.

cheers -ben