-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Controling the order of outgoing edges #112
Comments
Sorry for messing the dagre-d3 tracker. I'll try to look into the dagree code and hack something next week. |
I added Forster's constrained ordering algorithm which should give us the ability to constrain edge order while still being able to optimize ordering for edges that don't have constraints. While we could explicitly define ordering for each edge / node, it looks like the approach use by graphviz is more convenient. To enable this, we need to keep track of the order in which edges are added to the graph. This requires some change to graphlib. |
I'm going to need this feature for an application of mine in the near future. What's the current status of this bug? Is there anything a third-party can do to help get this running? |
went through the above link by Graphviz and it just says to add : {ordering: "out" OR "in"} so I did something like this:
and tried out as well, but still got the elements to jump sides any idea what Im doing wrong? |
The graphviz feature is not currently supported in dagre. |
Thanks @cpettitt so currently no option to set the order and not make the leafs swap? |
Not without a contribution. If someone were willing to work on it the pieces are already there with the constraint graph in the order phase, but they need to be exposed in an intuitive way through the public API. |
great, can u please elaborate more so I could dig into that? |
already been there but the links there to and I cant find them in the code as well |
Line 61 in a299bf8
|
We switch from Dagre for a number of reasons, including aesthetics and library maintenance status. But most importantly, by being tree-based, rather than working on arbitrary graphs, Tidy trivially gives us control over the left-to-right placement of sibling nodes, a feature _critically_ lacking in Dagre for our purposes. (An issue has been open for eight years, with the functionality frequently asked about (there are even multiple PRs purporting to fix it, though none with any real documentation): dagrejs/dagre#112. We might have realised sooner that this would be an issue, as our translation from tree to graph clearly does nothing to preserve child order, if not for the fact that somehow the order, despite being effectively non-deterministic (our experiments have shown it's not even lexicographic on IDs or anything else one might expect), is somehow correct a significant majority of the time. It's only now that we are able to build programs in-app again that this limitation has become clear.) Note that we do not _yet_ remove Dagre fully. It's still used here for layout of nested graphs (i.e. pattern boxes), pending a refactor. We now layout definitions "one tree at a time", by necessity, as opposed to the "combine everything in to one graph first" approach we used with Dagre. This results in, for now, larger gaps between trees. But this is something we wanted to explore anyway, regardless of Tidy, since the old trees often blurred together a little too much because of the lack of spacing. We can improve this in future by using a more sophisticated packing algorithm, whereas currently we just draw a bounding rectangle around each tree then juxtapose horizontally. Note also that how we build & import `@zxch3n/tidy` is a bit of a hack: - We build the package using our https://github.com/hackworthltd/tidy fork, via `nix-build -A packages.x86_64-linux.tidy`. - We create a `dist` branch of that repo and check into it the `dist`, `wasm_dist`, and `package.json` files from the `nix-build` step. - We add the package to `primer-app`'s `package.json` via a special GitHub URL; e.g., `github:hackworthltd/tidy#dist-rev` This works, but it's obviously not maintainable long-term. If we stick with Tidy, we'll need a different approach. (Note that using GitHub Packages' npm repository is a non-starter for us: see #638 (comment))
From @bzaborow:
Hi,
I started to use the dagre-d3 for visualisation of data similar to one of examples (the Sentence Tokenization). Extending this example to display a DAG instead of a tree was super easy, but I've lost control of an order in which edges leave a particular node. Is it possible to restrict it somehow? If not, could you point me where to start looking into your code? For my data the order of edges is quite important.
In fact, it would be the best if i could constraint nodes order too (position from left to right in top down graph), but as I understand, it is not possible at the moment (issue dagrejs/dagre-d3#25 ?).
Thanks
The text was updated successfully, but these errors were encountered: