Skip to content
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

Open
cpettitt opened this issue Feb 21, 2014 · 11 comments
Open

Controling the order of outgoing edges #112

cpettitt opened this issue Feb 21, 2014 · 11 comments

Comments

@cpettitt
Copy link
Collaborator

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

@bzaborow
Copy link

It should be possible to add an order attribute to nodes and edges in the input graph to indicate to dagre what the ordering for edges and nodes should be. This information could be used in the order phase instead of the barycenter heuristic. The implementation should be much simpler than that required for #25.

I'd be interested in what drives the requirement for edge ordering if you're at liberty to describe it. I can already imagine several reasons for wanting to explicitly order the nodes, though.

Sorry for messing the dagre-d3 tracker. I'll try to look into the dagree code and hack something next week.
And motivation for edge ordering: I'm working with linguistic data, syntactic structures in particular ("sentence diagram" and similar things). In languages where the word order is flexible, it's useful to mark a cannonical order of substructures. Example: words within a noun phrase - in English this will be determiner, then a number of adjectives and then a number of nouns, but e.g. in Polish you can put some of the adjectives after the nouns.

@cpettitt
Copy link
Collaborator Author

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.

@brianchin
Copy link

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?

@tzookb
Copy link

tzookb commented Feb 4, 2018

@cpettitt

went through the above link by Graphviz

and it just says to add : {ordering: "out" OR "in"}

so I did something like this:

var graph = new dagreD3.graphlib.Graph({ordering: "in").setGraph({});

and tried out as well, but still got the elements to jump sides

any idea what Im doing wrong?

@cpettitt
Copy link
Collaborator Author

cpettitt commented Feb 4, 2018

The graphviz feature is not currently supported in dagre.

@tzookb
Copy link

tzookb commented Feb 4, 2018

Thanks @cpettitt

so currently no option to set the order and not make the leafs swap?

@cpettitt
Copy link
Collaborator Author

cpettitt commented Feb 4, 2018

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.

@tzookb
Copy link

tzookb commented Feb 4, 2018

great, can u please elaborate more so I could dig into that?

@cpettitt
Copy link
Collaborator Author

cpettitt commented Feb 4, 2018

See dagrejs/dagre-d3#64 (comment)

@tzookb
Copy link

tzookb commented Feb 4, 2018

already been there but the links there to sweepUp sweepDown are not relevant anymore...

and I cant find them in the code as well

@cpettitt
Copy link
Collaborator Author

cpettitt commented Feb 4, 2018

function sweepLayerGraphs(layerGraphs, biasRight) {

georgefst added a commit to hackworthltd/primer-app that referenced this issue Dec 1, 2022
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))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants