graph autolayout testing

[forresto]

advantages:

• no need to tweak everything when editing middle of graph
• different views (ltr, ttb) for different people working in the same graph
• reasonable default view when opening any FBP or graph without node position metadata
• encourages grouping (~> code comments)
• collapse groups (~> code folding)

disadvantages:

• control

---

testing with yed's built-in algorithms on the photobooth graph

noflo manual

yed manual

yed organic

yed hierarchical ungrouped, left-to-right, octilinear edge

yed hierarchical grouped, top-to-bottom, othographic edge

[LowLevelMahn]

what about the CoDaFlow algorithm?

Graph Drawing 2014 Slides: http://lamut.informatik.uni-wuerzburg.de/gd2014/data/uploads/slides/3-friday/0900-gd14-talk.pdf Paper: https://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd14.pdf

[forresto]

@LowLevelMahn is that what's implemented in https://github.com/OpenKieler/elkjs ? KLay is deprecated in favor of ELK now.

[LowLevelMahn]

is that what's implemented in https://github.com/OpenKieler/elkjs

i can't find any relation/comparison to the CoDaFlow algorithm - different poeple involved, but also Kiel University - i don't know

KLay is deprecated in favor of ELK now.

saw that on the Klay Github page

[spoenemann]

@uruuru, can you shed some light here?

[uruuru]

The layered algorithm of ELK basically equals klayjs (it's simply a new version with more features and bugfixes). The reason for the new name is simply that ownership and code have been moved from Kiel University to Eclipse.

Codaflow has been a proof of concept that based on a completely different layout strategy, namely constrained stress minimization (which is available via the cola.js library). The parts that address further requirements for dataflow-like diagrams are not included in any release.

[LowLevelMahn]

cola.js is WebCola?

The parts that address further requirements for dataflow-like diagrams are not included in any release.

why - never reached a usable state?

[uruuru]

WebCola: yes.

The implementation was in Java using customized c++ libraries of the stress layout. We simply couldn't see a release strategy that seemed sensible and maintainable for us.

[LowLevelMahn]

The implementation was in Java using customized c++ libraries of the stress layout. We simply couldn't see a release strategy that seemed sensible and maintainable for us.

so the layout algorithm is good but not good enough to invest more time in finding a proper release strategy or port the C++ parts to Java - to become part of ELK in the end?

[forresto]

@LowLevelMahn chill. Open source maintainers are under no obligation to do anything that isn't in their own interest. They published a paper and didn't feel like porting it to ELK. Somebody else can do that, or make a new library.

[LowLevelMahn]

@forresto sorry it wasn't my intention to sound harsh in any way

@uruuru would it make sense to port the c++ code to java? or does codaflow never fully get out of the proof of concept phase?

[uruuru]

Let me put it like this: ELK layered has been fine-tuned for dataflow-like diagrams and their peculiarities over many years. While it has its limitations (some of which I believe could be overcome by using stress as a basis), it would require quite some effort to get a competitive Java-only implementation.

Apart from that and from ELK's general perspective, it would be nice to have constrained stress minimization as a further layout algorithm. However, a clean implementation isn't done within a day or a week I'd assume.

[LowLevelMahn]

what about releasing it "as is" on github as a (small) first step - with your last comment as README.md :) so people like me reading the paper/slides about CoDaFlow can find some related material