|
Re: Hierarchy crossing edges with multiple layout runs [message #1787062 is a reply to message #1787052] |
Fri, 18 May 2018 08:00 |
Christoph Daniel Schulze Messages: 98 Registered: September 2015 |
Member |
|
|
Hi Mats!
Mats Wilhelm wrote on Thu, 17 May 2018 21:40I was thinking about different approaches, maybe someone can eliminate or encourage one of those or give a new suggestion :-)
Sure, here we go. ;)
Mats Wilhelm wrote on Thu, 17 May 2018 21:401. Current implementation:
- A Layout run for each hierarchical node. Hierarchy handling set to separate children.
- Result: Ignores edges that cross hierarchy boundaries while everything else works.
True hierarchy-crossing edges are only supported by few layout algorithms (only ELK Layered, to be exact), and only if hierarchy handling is configured to include children. This is because the layout algorithm needs to have control over all involved levels of hierarchy to be able to route the edges properly.
Mats Wilhelm wrote on Thu, 17 May 2018 21:402.
- Like 1., but with a final layout run with algorithm "org.eclipse.elk.layered". Then fix every nodes position and only apply edge bend points.
It's highly unlikely that this will give proper results. There is currently no way to configure ELK Layered to only compute bend points, and even if you only applied the bend points they would not fit the node positions.
Mats Wilhelm wrote on Thu, 17 May 2018 21:403.
- A Layout run for each hierarchical node. Hierarchy handling set to include children.
- Result: Only the last run's result is visible after layout. Is there a possibility "clearLayout" option can change something here?
This will indeed always reset the layout of hierarchical nodes included in other hierarchical nodes. It's not a viable option either.
Mats Wilhelm wrote on Thu, 17 May 2018 21:404.
- Like 1., but with hierarchy handling set to include children and include the incoming/outgoing edges of nodes in that layer and their corresponding second node too.
I'm actually not sure what you mean by "include the incoming/outgoing edges of nodes in that layer and their corresponding second node too." ;)
In the long run, an ideal solution would be to simply ignore hierarchical edges, set hierarchy handling to separate children, and to run an edge routing algorithm on the hierarchical edges. Alas, we don't have a dedicated edge routing algorithm yet (it's high on our to do list, but we'll have to find somebody to implement one since that's not exactly a trivial enterprise). So for the time being, one option would be something that we do in these cases in our applications:
- Configure hierarchy handling to separate children to have every hierachical node laid out by the intended algorithm. Ignore hierarchical edges for now.
- When applying the layout results in your layout connector, look for the hierarchical edges and manually compute their end points such that they directly connect their source to their target.
See this method for an example of how we implemented such a solution.
Hope this helps!
Cheers,
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.03463 seconds