Comment #2 on issue 845 by google....@ben.coman.com.au: some Roassal layouts broken when nested http://code.google.com/p/moose-technology/issues/detail?id=845
To summarize results shown in the graphic, for nested elements, the following are broken: RORadialTreeLayout ROSugiyamaLayout ROHorizontalTreeLayout ROForceBasedLayout ROScatterplotLayout ROTreeLayout
The following appear to work fine nested: ROGridLayout ROVerticalLineLayout ROHorizontalLineLayout ROBottomFlowLayout ROFlowLayout ROCircleLayout
In addition, I guess it gets a bit tricky when edges cross the boundary of parent elements - particularly with the force based layouts. I remember bumping into an issue with Mondrian where the nested elements were dragging the parent elements over the top of each other. A brief thought on this is that edges that cross parent boundaries should be handled in two parts.
1. Outside the parent - the edge should "act" in the layout of the parent that is common to the child-elements at each end of the edge.
2. Inside the parent - the point where edge crosses to the border of parent becomes a proxy for the other end of the edge. This way the "distance" that multiplies the force has less impact on the local layout within the parent.
So in the attached image, for the edge between B & G, the force layout will try to bring point 10 & 11 together, but not point 9 & 12. When 10 & 11 are close, the repulsion between C & H should dominate rather than still trying to bring B & G together.
Similarly, for the edges between I & A and I & B, once A & B are up against the bottom edge of C, the small distance between 1 & 2 and 5 & 6 should allow repulsion between A & B as well as the bottom edge to dominate - rather than the greater distance between 1 & 4 and 5 & 8 forcing A & B to overlap. In addition, the position of I within K should not be affected since K does not have a circle layout.
This brings me to another passing thought... I think it is a little undefined what happens if you apply one layout to some child elements of parentA, and a different layout to other child elements of parentA. Perhaps rather than applying layouts to a group of elements (eg ROGridLayout on: el elements), a layout should just be applied to a single element, which arranges all elements contained there-in (eg ROGridLayout on: el). For the case above, this would require the two sets of elements to be part of subParentB and subParentC, each having different layouts.
btw, I can't remember seeing any cases where I haven't applied a layout to all child elements of a node.
!So there are likely lots of complications I haven't considered and more than can be dealt with in a single issue, I'm just brain dumping in proximity to the topic that sparked these thoughts.
Attachments: Interparent force layouts.png 25.2 KB