Show HN: A Graphviz Implementation in Rust
github.com
github.com
This library looks really promising! As it's written in rust, it should be possible to port it to WASM. Are there plans in that direction?
Is it planned to be a drop-in replacement for GraphViz (or the dot engine)?
[1]: https://edotor.net [2]: https://github.com/mdaines/viz.js
awesome-network-analysis #javascript lists a few libraries. https://github.com/briatte/awesome-network-analysis#javascri...
FWIW, JupyterLite builds WASM as well
I tend to stay away from Graphviz a lot more than I otherwise would these days due to the lack of manual formatting controls (have spent waaaayyy too many hours writing code to add invisible edges between certain nodes to force row-ordered layouts).
"Best to think of Graphviz as a competent but unruly teenager"
and then just be glad you did not have to do the work yourself.
It would probably be helpful to the community if we could add a layout plugin to allow users to specify layouts in some absolute or relative grid format, to avoid all the invisible edge and edge length hackery. We just need appropriate funding.
We have some amazing maintainers who work on gitlab.com/graphviz/graphviz now, but the think is, there are far more bug reporters than bug fixers. The first gen of Graphviz authors are timing out, so we very few people are around now to fix relatively deep semantic or logical bugs, c.f. https://xkcd.com/2347/
Best regards, Graphviz the Project
In case you come back to revisit ... First I will note my comment appears nested one level deeper than I had been aiming for which may make it sound less positive than I intended. Second, Graphviz doesn't need to do anything to appease control freaks. You have been absolutely rocking it for decades. The important part of my glib description is 'competent' and to accept the very, very fair tradeoff between; already done with minimal effort and satisfying some fashion police insisting you do it their way when in reality they can't produce results themselves.
The bottom line is, I can not thank you enough for releasing your software way back when I built it on my Amiga, you have been a constant companion in my career.
I use scripts to manually place everything from data in csv files.
What do you mean? You can always specify the exact coordinates of some vertices:
3 [pos="20,30"]
Pos doesn’t work with most layout engines (most notably dot), making it kinda useless, and graphviz doesn’t easily expose the dimensions of a node to accommodate dynamic layout. You can work around that, but that’s nowhere near as ergonomic as some sort of “tree level”-like argument that would force a node to position at a certain Y-coord while leaving the automatic layout process otherwise intact.
One of the things I rarely see in other graphing tools is the concept of node clusters. Super helpful in a bunch of situations I've encountered and wish it was more broadly implemented in other layout engines.
I've generated diagrams from various sources of data in AWS (security groups, EC2 instances w/ their attached security groups, edges between, etc) and never run into this issue. I'm talking thousands to tens of thousands of nodes and tens of thousands of edges.
The utility of these diagrams was limited, given how dense they were. I'm curious what use case graphviz chokes on that would generate legible graphs..
edit: this reminds me that it would be useful for the AWS APIs to return a "modification epoch" number inside API responses, so that while you're enumerating/describing thousands upon thousands of resources, you could at least keep track of whether there have been any modifications between your first and your last Describe* call.
None of these tools are actually appropriate for the job, just never get the time to build something better.
Some nice clever person could probably code up that clever algorithm of Brandes and Köpf, https://link.springer.com/chapter/10.1007/3-540-45848-4_3
Some nice clever person could probably replace our 1990s-style network simplex solver with something that takes advantage of multiple CPU cores, too.
But man, endlessly fiddling to fix the layouts is time I'd like back in my life
I know many engineers are perfectionists, but pick your battles. It’s not as if the alternative of manually laying out every node and edge and maintaining it is universally better.
And your text-based diagram tools. Kroki[1] has merged block, sequence, Plant UML, packet, Mermaid, GraphViz, and numerous other textual diagram formats into a simple REST API. A while back I integrated the API into my text editor so that I could use variables inside of diagrams[2] (such as character names in a sci-fi story that are also presented in a GraphViz-based family tree).
[1]: https://kroki.io/
[2]: https://github.com/DaveJarvis/keenwrite/blob/master/docs/scr...
What is the current status? Not seeing it listed anywhere, like if there are features that are not supported or if it uses certain layout algorithms but others are desired.
Would you be willing to make a `[lib]` available? I see you have a `lib.rs` but it'd be great if using it didn't require pulling in `[[bin]]` dependencies (you can mark them as optional and mark `required-features` on your bin like pulldown-cmark does [0] or split it into a separate crate in a workspace). It'd also be good to find an available name for the lib and get it published (looks like someone might be squatting on `layout`).
[0] https://github.com/raphlinus/pulldown-cmark/blob/master/Carg...
--> src/core/color.rs:180:21
|
180 | for pair in KNOWN_COLORS {
| ^^^^^^^^^^^^ borrow the array with `&` or call `.iter()` on it to iterate over it
|
= help: the trait `Iterator` is not implemented for `[(&str, u32); 148]`
...
error[E0277]: `[geometry::Point; 20]` is not an iterator
--> src/topo/placer/edge_fixer.rs:272:39
|
272 | for offset in offsets {
| ^^^^^^^ borrow the array with `&` or call `.iter()` on it to iterate over it
It even makes lots of Rust's documentation examples more readable. Previously if there's an iterator involved somewhere, the doc example ends up constructing say vec![1,2,3,4,5] and a reasonable novice might ask why do we use a vector here? Today Rust's documentation just says [1,2,3,4,5] because sure, an array of five elements 1, 2, 3, 4, 5 that makes sense why use any other data structure?
I have worked on graph visualisation for some time, did https://github.com/nikolaydubina/jsonl-graph and https://github.com/nikolaydubina/go-graph-layout
Been studying research papers on graph visualization.
It looks like we need some Deep Learning / ML based approach to this.
There is just so much meaning is encoded into XY coordinates and edges. Basic algorithms like Sugiyama produce meaningful visualizations only for simple and basic graphs.
When number of edges goes to the roof or nodes.. basic algorithms break down. Graphs become meaningless.
You have to make graphs by hand to make sense of it.
ML approaches to graph layout are very exciting, since the constraints people need in real life diagrams are quite intricate, but it's still a research problem.
ML would def benefits here to capture all these heuristics.
https://rust-lang.github.io/api-guidelines/necessities.html#...
We need to support and keep this system alive!