By now I also have a few ideas how to get the edge paths to be much better (and built-in Bézier spline routing would have helped, but that was only released publicly. But we kinda ran out of time, so I only managed to fix the most egregious problems. I've tried to make it mobile-friendlier, after our marketing team told me that most people who come via Twitter use a phone. (yWorks employee here, having worked on that Graph Drawing Contest) (At times I resorted to annotating the code with magic comments to facilitate graph generation - not a sustainable approach.) But a day spent hacking with Graphviz dramatically improved my learning rate, and it was also useful in helping describe the code to others. It was an awful, throwaway hack, and was only about 90% accurate due to parsing/preprocessor challenges. Every node was clickable, and would ask the Web app to generate a new graph centered on that node. The "app" let you click on a function (node) and zoom in to examine its callers, callees, global accesses, global mutations, etc., with a "radius" parameter to decide how much of the large graph you wanted to see. I used a C parser (forget which one) to convert the code to a set of ASTs, and then hacked up a Web-based, interactive graph generator, using Graphviz to create the interactive SVGs. My favourite personal use of Graphviz: A few years ago I inherited a large, legacy codebase that was very hard to understand - full of global state modified from dozens of functions, obscure function names, etc. (I wouldn't say "no" to having more layout algorithms, though!) I don't care if graphviz looks a bit dated - it's straightforward and easy to generate. You want to tell it node sizes and have it tell you where to put them.Īgreed 100%. This isn't just for looks, either: if you want the resulting graph to be interactive, and perhaps even graphically (drag-n-drop) editable after the initial graphviz auto-arranging, you're probably wanting output that's not exactly in graphviz's wheelhouse. Much cleaner (and way more useful) to be able to tell graphviz "this is how large I need this node to be, and that one this size, and the other one such-and-such, and they are connected thusly, now please give me coords for a layout" If you apply, say, a typeface or padding even very slightly different than what graphviz was using, or if there are just slight differences in, say, how a given browser renders a, it could change the size of the rendered nodes, and you end up with edges drawn under/over nodes. It's important (for what I'd like) that graphviz know how large each node is going to be so it can route around them. That doesn't let you tell graphviz how large you want to draw each node, right? Just how large graphviz would draw them? What I'd like is a way to take styling and drawing outside GraphViz. it would be a big effort, but move the core algorithms to a framework that supports interaction with layout generation find someone to donate a generic orthogonal routing algorithm based on a modern algorithm since people want this better documentation to help people find useful tools or just know what they should be looking for more robust handling of error conditions like out of memory more expressive graph language with classes or templates better default layout parameters in neato than statistical multidimensional scaling based on shortest path better default styles that don't look like troff from 1985 Improvements that would benefit the community the most? We've gotten a lot of help lately from Magnus Jacobsson, Matthew Fernandez and Mark Hansen on cleaning up the website and the code base, even some persistent bugs we could never find ourselves. We're reluctant to be exposed to too much anger about misfeatures in 20 year old code that was basically a prototype that escaped from the lab, but go ahead, ask us anything.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |