sigmajs support

[psychemedia]

How easy would it be to integrate support for the sigmajs visualisation library?

I think the json graph representation that sigma.js accepts matches the one use by the d3.js network layout?

[fkling]

I'm not sure whether an integration would be the right approach. I think the easiest thing to do is have a converter function which converts a graph into an object of the format sigmajs expects. Have a look at https://github.com/fkling/JSNetworkX/blob/master/jsnx/convert.js#L202 for example. It really should be difficult.

But if you had seamless integration in mind, such that adding a node to the graph also updates the visualization, I don't know if that's even possible. I'd have to have a look first how sigmajs works.

[psychemedia]

In what sense does the current drawing support demonstrate a "close integration" and to what extent is it a packaging of a graph into the format the drawing library supports?

Thinking about something like rCharts, which provides a generic R wrapper for a variety of js charting libraries, selecting an "integrated" chart library would mean you could as a user define a JSnetworkx library, specify the chart library type, and then "just" render the output display?

[fkling]

First of all, I think sigmajs and JSNetworkX try to solve the same problem: Visualize graphs. On top of that, JSNetworkX also provides the means to model and process graphs.

In what sense does the current drawing support demonstrate a "close integration" and to what extent is it a packaging of a graph into the format the drawing library supports?

JSNetworkX actually uses its own drawing solution, built on top of D3.js and SVG. Both are really low level parts and JSNetworkX adds the glue to handle graph specific logic. Neither D3 nor SVG know what a graph is.
It is tightly integrated because the drawing solution expects JSNetworkX graph objects as input and is built around the graph API. That makes it possible, for example, to more efficiently update visualizations when the graph changes.

Don't get me wrong, I love the idea to be able to use other existing visualization solutions with JSNetworkX. I'm just thinking about what would be the best way to do that.
For example, I started working on a more generic drawing API, so that I can use different rendering engines to visualize a graph, e.g. WebGL instead of SVG. And this works fine because those engines don't provide any logic for graphs on their own.
But it somehow doesn't feel right to hide a full-fledged graph drawing API behind JSNetworkX's own API. That's why I think, having a function that simply converts a JSNetworkX graph to sigma.js' input format might be sufficient... for now. If more features are desired, so that for example the visualization is automatically updated when the JSNetworkX graph object is changed, then we surely need more logic to make that happen, at which point an actual support for sigma.js on side of JSNetworkX makes sense.

---

But in general, JSNetworkX can be already used with any graph visualization library out there, as long as a graph can be converted to the desired input format. The best thing (for JSNetworkX) would be if the visualization libraries themselves would add support for JSNetworkX graph objects.

I also understand that something like rCharts is desirable, but I don't think that this is the role of JSNetworkX. It could be another project which connects JSNetworkX graphs (and other graphs) with those libraries. Making JSNetworkX feature complete is already work enough (especially, and unfortunately, given my little time), maintaining compatibility with X different visualization libraries would be too much. I'm very happy to support such an effort though, if anyone wants to tackle this :)

[psychemedia]

"That's why I think, having a function that simply converts a JSNetworkX graph to sigma.js' input format might be sufficient"

Yes - agreed; in networkx, http://networkx.lanl.gov/reference/readwrite.json_graph.html returns serialised data that I have plugged directly into visualisations built on top of d3.js demos.

I guess it's a design issue as to whether third party libraries should accept JSNetworkX graphs or whether JSNetworkX should support export plugins to handle data transformations into graph representations used by the third party libraries. (I wonder, is there standardisation work going on around graph representations in JSON?).

Re: the rCharts approach - that is, maybe, another project. There is already an rMaps effort, so maybe there's an opportunity for rGraphs too!

[fkling]

Closing this now. nodes() and edges() provide an easy way to "extract" the graph data. For example, one could do

var data = {
    nodes: G.nodes(),
    edges: G.edges()
};
// Really need JSON?
var json = JSON.stringify(data);