Comment #2 on issue 845 by
[hidden email]: some Roassal
layouts broken when nested
http://code.google.com/p/moose-technology/issues/detail?id=845To 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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Locked
