Groups   152 of 99+      julia-users › Coordinates of graph layout algorithms 12 posts by 6 authors      Tom Breloff    Feb 10   I'm thinking through a nice way to implement visualization of graphs   48  in Plots.  I think what makes sense is to use something like https:  github.com IainNZ GraphLayout-jl, but without the dependence on Compose.  I guess my questions: is there a better  lightweight  alternative to GraphLayout for determining the coordinates for drawing graphs?  Should I submit a PR to GraphLayout in order to separate the  layout algorithm  from the  Compose drawing ?  I would much prefer a pure-julia solution if possible.  Thanks, Tom     Tom Breloff    Feb 10   Here's a basic first pass at this: https:  github.com tbreloff ExamplePlots-jl blob master notebooks graphs.ipynb  The gist is that I'd like to build a  simple_graph , then extract the x y coordinates of the nodes given some layout algorithm.  It seems like the  layout_spring_adj  gives me the coordinates I want, but this is the only method I can find which works.  I'm trying to decide whether I should submit PRs to GraphLayout to separate generation of the x y coordinates for the other algorithms... any opinions?      Tomas Lycken    Feb 10   Without having looked at the code, I'd say that such a separation effort is definitely the way to go  in fact, I created the Contours-jl package for very similar reasons, based on code originally in Gadfly . I would even think it makes sense to move the Compose-based drawing into Gadfly, to make the GraphLayouts package independent of drawing backend  and thus reusable by other plotting packages too . This might be a too big operation to handle in one go, though.     T      hustf    Feb 10   There was an inspiring related thread a little while ago:  https:  groups.google.com forum  !searchin julia-users graph$20glvisualize julia-users ybGrFVKGyDA KEf6mY0mCwAJ  My impression is that this subject is full of heuristics, and for graphs like e.g. the complete Julia package system I believe interactivity is the most effective heuristics there is. Compose can't offer that so I have simply used a text file with a blacklist of nodes to remove, and a function to remove disconnected nodes.  One of the other heuristics to graph layouts is going 3d, projecting your nodes on a sphere, a torus etcetera. That's fascinating in itself. You can start out with a 2d layout and the spring stiffness model or your own variant of it. But if it never settles into a clarifying layout for the purpose, you may take that incomplete layout and project it on a spherical surface and voila you get clarity. Or a torus. This is quite fun. It's neither lightweight nor easy nor fully compatible with Mac OSX, but a more complex graph layout application with interactivity could be built using the current state of GLVisualize. That state, of course, is changing rapidly.      Iain Dunning    Feb 10   For tree layout, the way you're plotting it and the layout algorithm go pretty naturally together, but for just the force spring ones, its not a big deal. I don't really have time or much interest in keeping on working on that package, I probably shouldn't have registered it in the first place. Maybe I should deprecate it.      Andreas Lobinger    Feb 11   Hello colleague,  i touched the topic of a 'layout engine' a few times in various julia plotting discussions and would really like to see a package that deal with this, with an abstract interface and not tied to a special rendering step  different than d3.js . Graph layout would be a sub task of this. Actually Compose-jl is in some sense a layout engine of it's own, so at least there would be some parallel work.   I'd be in favour of a dedicated graph layout package and i'd recommend to start fresh and import working code from the available kits.     Andreas Lobinger    Feb 11     On Thursday, February 11, 2016 at 12:13:21 AM UTC+1, hustf wrote: There was an inspiring related thread a little while ago:  https:  groups.google.com forum  !searchin julia-users graph$20glvisualize julia-users ybGrFVKGyDA KEf6mY0mCwAJ  My impression is that this subject is full of heuristics, and for graphs like e.g. the complete Julia package system I believe interactivity is the most effective heuristics there is. Compose can't offer that   I'm not fully in the picture, but it looked like Tim Holy has already extended a local Compose  re- implementation for Immerse-jl for more interactivity.      Tom Breloff    Feb 11   Iain: since the package is yours, would you like to transfer it to an org  JuliaGraphics?  or would you prefer that I just copy paste some of your code into a new package?  It seems a waste to deprecate it!     This message has been deleted.    Stefan Karpinski    Feb 11  Re:  julia-users  Re: Coordinates of graph layout algorithms  What is needed is people willing to share the maintenance work – Iain does a huge amount of work in the Julia ecosystem. How about stepping up?  On Thu, Feb 11, 2016 at 12:08 PM, hustf  fro... gmail.com  wrote: GraphLayout is a nice and useful package which would be a pity to deprecate. Perhaps what is needed is just the courage and enthusiasm to change the interface or delete the less useful or tough to maintain parts?      hustf    Feb 11  Re:  julia-users  Re: Coordinates of graph layout algorithms  Yeah, I deleted that message because it was not very constructive. Let me continue:  GraphLayout is a nice and useful package which would be a pity to deprecate. Perhaps what is needed is just the courage and enthusiasm to change the interface or delete the less useful or tough to maintain parts?  A bit of creative destruction might be an advantage. The package was more or less broken for months because of dependencies. If the output was a flexible set of lines, circles, boxes, text, coordinates perhaps? Graphic interfaces are going to continue to be hard to maintain on the various systems.      Tom Breloff    Feb 11  Re:  julia-users  Re: Coordinates of graph layout algorithms  I'm willing to step up!  I just don't want to step on Iain's toes.  My plan would be:  - strip out all drawing-related code - simplify the interface - add some  _apply_recipe  methods in Plots for Graphs-jl objects, which would abstract the drawing from both the layout and the backend  Then the  lines, circles, boxes, text...  would live in Plots, and the low-level drawing commands are not needed.