How to avoid the layout to change the children order when adding a new node?

[Vadorequest]

I'm using reaflow which uses this library.

When we add new nodes, the canvas redraw itself and somehow "optimize" things.

While it's nice at the beginning, it can also be confusing. For instance, in the below video, the last node added changes the order of the ascendant nodes (inverts them) and this is highly confusing for the end-user.

Is there a way to configure this behaviour anyhow? It seems to be related to the LayoutOptions but I don't understand how I could change the current behavior. Also, the typings for LayoutOptions weren't really useful to me.

elkjs/typings/elk-api.d.ts

Line 10 in 76c9203

[key: string]: string

I plan on making a collaborative editor, I'd need to avoid the graph to "jump" as soon as somebody adds a new node. 😬

Basically, I'd want the graph not to reorder existing children (nodes).
While the order isn't really relevant to me, it's confusing for humans if things jump too often.

---

Video: https://youtu.be/4JPPXlyoRQ4

Before node added:

After node added:

[Vadorequest]

Maybe one of the option at http://kieler.github.io/klayjs-d3/examples/interactive/ (mentioned in the README How to enforce certain node positioning (topological)) would help?

Not sure, kinda lost in what are the available options.

I think it might be related to nodeLayering: 'INTERACTIVE' in layoutOptions, but I'm struggling to figure out what the other options are...

[uruuru]

I believe you can find (unsatisfying) answers in #100 and the issues linked there.

If not, let me know.

[Vadorequest]

@uruuru Thanks, it "helps". 😅

Is there a way to stop all automation (auto-layout, auto-placement of nodes and edges) anyhow? I believe changing the algorithm might do the trick, and then placing each element manually, or semi-automatically might be possible?

My ideal world: Having ELK place elements (nodes/edges) as automatically as possible, but not change the placement of things that've been positioned already. If it's not possible, then an alternative might be to disable all auto-placement and implement my own algorithm for this, but I'm not sure either of those 2 options are feasible.

[Vadorequest]

Other questions:

• Is http://kieler.github.io/klayjs-d3/examples/interactive related to ELK? I saw it mentioned somewhere, but I'm not sure if it showcases ELK feature or if it's completely different.
• Is there any reference to nodeLayering somewhere? It was mentioned by @amcdnl in Improve Types/Docs #113 but I couldn't find any reference anywhere (and I've been looking deep)

[uruuru]

Answers:

My ideal world: Having ELK place elements (nodes/edges) as automatically as possible, but not change the placement of things that've been positioned already.

In general, no. You can omit parts from the layout process using the noLayout option (which sideeffects). You can set fixed as algorithm for certain nodes which will preserve the specified positions of those node's children. You can use the interactive strategies, see under User hints on the examples website.

Is http://kieler.github.io/klayjs-d3/examples/interactive related to ELK? I saw it mentioned somewhere, but I'm not sure if it showcases ELK feature or if it's completely different.

klayjs is the (deprecated) predecessor of elkjs. Hence, yes, it showcases features that should still be part of elkjs.

Is there any reference to nodeLayering somewhere?

Node Layering

[Vadorequest]

I might be dumb, but I don't get how the nodeLayering option is related to the "Node Layering" link you mentioned.

Why is it defined as nodeLayering in ELKjs, instead of org.eclipse.elk.layered.layering.strategy? Or is it unrelated (but then, what is it and what does it do?).

Using fixed for all my nodes might do the trick then? I need to give it a try.

[Vadorequest]

How do you find options in the documentation? I'm looking at the reference page at https://www.eclipse.org/elk/reference/options.html and can't find options such as noLayout unless I know the parent namespace (which I don't).

It'd be great to have some search feature there.

Would you mind sharing the link for the documentation of the node "fixed" you mentioned earlier? I couldn't find it either 😢

[uruuru]

• In klayjs org.eclipse.elk.layered.layering.strategy was called nodeLayering. During a the shift from kieler to elk it was renamed.

• Regarding search: simply use your browser's text search:
  

• Fixed Layouter

• If you have ideas how to improve the website, feel free to provide a PR. The sources can be found here: https://github.com/eclipse/elk/tree/master/docs

[Vadorequest]

Okay I see, you use https://www.eclipse.org/elk/reference/options.html page to perform searches.

So, the nodeLayering shouldn't be valid anymore, shouldn't? I guess it won't do anything if used?

Does the "algorithms" (such as https://www.eclipse.org/elk/reference/algorithms/org-eclipse-elk-fixed.html) apply to the layout only, or do they apply to nodes as well?

Because you mentioned I could apply a fixed algorithm to nodes, specifically (instead of applying it to the whole layout), but it's not clear from the doc whether they support the same options or a different set of options. I couldn't find documentation about the algorithms supported by the nodes, specifically. (and my attempts to apply a fixed layout to all my nodes have failed so far)

[uruuru]

So, the nodeLayering shouldn't be valid anymore, shouldn't? I guess it won't do anything if used?

Yes, It used to be a legacy id that was still evaluated. The legacy ids have been removed in the last release, though.

Does the "algorithms" apply to the layout only, or do they apply to nodes as well?

A layout algorithm is applied to the children of a node. See this example for an illustration.

you mentioned I could apply a fixed algorithm to nodes, specifically (instead of applying it to the whole layout)

I was implicitly referring to "parent nodes", i.e. if you configure fixed for node n1, whose children are n2 and n3, then you can specify positions for n2 and n3. These positions will then be preserved and the size of n1 will be adjusted accordingly. There's no option, however, to mix different layout algorithms on the same hierarchical layer such that sibling nodes are treated differently.

[Vadorequest]

Thank you, I understand better what I did wrong now.

I guess a workaround for my use-case could be to have a global parent node containing all other nodes and edges as children, for those nodes to be able to use a fixed position. It's definitely a workaround, but still might help regarding manual node positioning.

[meoyawn]

hi @Vadorequest, how did you ultimately solve this? How can I get in touch with you? Thanks!

[Vadorequest]

@meoyawn I didn't solve it, nor did I implement a workaround.

[im-amir]

@meoyawn @Vadorequest Were you able to solve it? or did a workaround or anything?

[meoyawn]

@im-amir no 😕. I decided it's better to have manual layout by default and auto layout only on demand

[im-amir]

@meoyawn can you please share the link for how you implemented with manual layout? maybe that helps!

[meoyawn]

@im-amir I do not, sorry

[soerendomroes]

How about the solution described here #187