Hacker News Reader

Comment by anonymous532 | Hacker News Reader

It's cute and definitely a great way to "draw S-curved arrow between boxes", but, under the assumption of being built to be used within a real project with dozens or hundreds of overlapping connections, this, like many other node systems, fails to be usable unless you push the complexity somewhere else.

View on HN

Is someone selling it as some kind of universal solution for production diagramming problems of all scales, or is this just unnecessary negativity?

> under the assumption of being built to be used within a real project with dozens or hundreds of overlapping connections

This is an odd assumption to make.

Not so weird. Here's a random example, from Wikipedia:

https://en.wikipedia.org/wiki/Force-directed_graph_drawing#/...

These are straight lines. Not sure you even _want_ Bézier curves in this context, striaght lines are probably clearer in these graphs with hundreds of connections.

Ah, good point.

In that case the tool would need to lay out everything holistically but while it might do great arrow wise it could be useless for the user if they wanted the diagram a certain way for a reason.

Yes, that is what I've noticed too. On medium/big projects macro-level(holistic) arrow functionality is far more important than having beautifully curved arrows from node A to node B. Solving that problem strangely resembles routing on a circuit board with buses, labels, colors, layers etc.

There is a section in Graphics Gems 3 that describes a layout system for an Atari ST DAW app.

Which chapter in Gems III has this? I couldn’t find it.

but it's solving one part of the problem, and doing a good job at it. I've been making diagrams using graphviz, but setting the positions and edge curves manually, pulling the nodes and edges out of a list in excel

https://github.com/mathew-j-davis/boxesandarrows

I've been setting the 'waypoints' for more complex curves (curves with many bends) manually (typing the bezier numbers in by hand), while I try and figure out how I want them routed, you're right it's not easy figuring out rules for where edge should go, let alone implementing it

I think it depends on the use case and the organization/ordering of the boxes, which is not the focus of this library.

So for example, if the user is responsible for organizing the boxes and there is also a way to create custom arrows, this library can be used to suggest arrows, which might be good 95% of the time. That would be better than many of the tools I have used over the years.

However, if you want to generate a final diagram and can't guarantee, that the order of boxes doesn't allow for overlapping connections, this library is probably the wrong choice.

I don’t think the author is making any claims about the algorithm being able to handle more than the 2 box case. Why the negativity?

Reply on news.ycombinator.com