I just published a little app to draw graphs: https://git.sr.ht/~akkartik/snap.love I've wanted something like this for a long time. Intended for small graphs where laying things out by hand is not too painful, and it's nice that things don't move around every time I make a change, as happens with graphviz (https://graphviz.org). The file format is also amenable to git; no long lines, and adding new nodes or edges doesn't reorder unrelated nodes and edges. Immediately after sharing it, I notice that there's also a limit on the number of edges. Too many edges, and the dumb layout algorithm (connecting centroids of nodes) starts to creak.

“t’s nice that things don’t move around every time I make a change’ == UX

I built it by dropping Lua into boxes 🙂 https://git.sr.ht/~akkartik/driver.love Not 0D, though, it's been on my mind to look more carefully at your recent projects.

I guess the "export" function is "screenshot"? Which I think is perfectly fine for this type of application. Though I wish graphics platforms systematically had "save as SVG" for whatever is drawn in a window.

Yeah, no reason it couldn't. Lines.love has SVG export, should be easy to port over.

The difference between boxes drawn by normal humans and boxes drawn by programmers is decoupling. Normal humans draw boxes that are asynchronous (e.g. boxes drawn on a whiteboard), programmers draw boxes that are synchronous (which leads to hating VPLs). Rhetorical questions: Can Queues (LIFO) be created in Lua? Does Lua have anonymous functions (closures/whatever)? If so, then full decoupling (which I call 0D ATM) is easy. :-) One more step: create 2 kinds of boxes: (1) code and (2) routing. Boxes of type 2 (Containers) are recursively defined - they can contain boxes of type 1 or type 2. In Lisp, type 1 boxes are called Atoms and type 2 boxes are called Lists. In my vocabulary, 1=Leaf, 2=Container.

For https://nodysseus.io I went with autolayout only. To make that possible, it's got a tree structure - nodes have multiple inputs but only one output. This mimics some good programming practices too, so it works well.

That's cool! I poked at autolayout for an earlier app: https://git.sr.ht/~akkartik/mastodon-unfurl.love I may well do more with it.

# Auto Layout Is A UX Disaster IMM, auto-layout results in disastrous UXs. There are two kinds of code: 1. code for controlling machines, code that is machine-readable 2. code for communicating to human readers why code for controlling machines has been written the way it was - DI, Design Intent. Code that is human-readable. When laying out code for DI - human consumption - spatial relationships matter. Do you want power-assist to help you lay out spatial relationships? Yes. Do you want power-assist to change the layout every time you make a change? No. When laying out code for machine consumption, spatial relationships don’t matter. Current electronic machines (aka “computers”), work only with sequential relationships. Spatial layout doesn’t matter to machines. Auto-layout applied to this kind of code is just a waste of electrons. Summary: layout only matters to human readers. Human readers grok things that are laid out spatially. Each time the layout changes, human readers need to expend brain-power to re-grok what’s being presented. Brain-power is bounded - users can burn brain power to think, or, they can burn brain power to re-grok what they’ve already grokked.

@guitarvydas have you given nodysseus a go? Here's a tutorial showing a bit more of the autolayout behaviour.

There's nothing intrinsic to autolayout that requires layout to change every time you add/remove a node. As an obvious example, you could add the existing positions of all existing nodes as constraints to the solver. Perhaps this over constrains the problem, but I think it's under studied.