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

Updates: Labels: Component-Roassal

Comment #4 on issue 845 by alexandr...@gmail.com: some Roassal layouts broken when nested http://code.google.com/p/moose-technology/issues/detail?id=845

I am not sure to fully understand this issue. TreeLayout works well when embedded.

try the following: -=-=-=-=-=-=-=-=-=-=-=-= outterNode := ROElement new + ROBorder blue. elements := ROElement spritesOn: (1 to: 5). outterNode addAll: elements. rawView add: outterNode. rawView addAll: (edges := ROEdge linesFor: (Array with: elements first -> elements second with: elements second -> elements fifth with: elements second -> elements third )). ROTreeLayout on: elements. -=-=-=-=-=-=-=-=-=-=-=-=

I've added this example in ROExample>>nestedLayoutOn: it is therefore accessible from the example section in Roassal

Comment #6 on issue 845 by benjamin...@gmail.com: some Roassal layouts broken when nested http://code.google.com/p/moose-technology/issues/detail?id=845

I think it is still an issue but I don't have time to explore it fully this month. Can it rolled over to version 4.8?

Comment #8 on issue 845 by benjamin...@gmail.com: some Roassal layouts broken when nested http://code.google.com/p/moose-technology/issues/detail?id=845

I don't have time right now, so close it. Later if it turns out to be a problem longer term I will get more data before I would ask for it to re-opened.