On Tue, Mar 4, 2014 at 6:34 AM, Björn Grüning <bjoern.gruen...@gmail.com>wrote:

> Hi Carl,
> Am 03.03.2014 21:13, schrieb Carl Eberhard:
>  Hey, Bjoern
>> Not sure whether a pull request or a toolshed repo would be best, but: if
>> you decide on a toolshed repo, graphview as it is should be able to use
>> your datatypes if they include a 'node-edge' dataprovider.
> How can that work? If we migrate all graph-datatypes to the toolshed,
> graphview needs to depend on it, or?

I hadn't considered moving the *existing* graph datatypes to the toolshed
as part of the plan, but if we do graphview doesn't necessarily need to be
moved as well (although that would make things more consistent).

The registry and graphview's configuration file just check whether a
dataset has a dataprovider named 'node-edge'. There's no code shared
between them so it's not dependent on the datatype or dataprovider code.

At the very least, moving graphview a seperate decision. Also, it's worth
noting that there currently is no distribution of visualizations from the
tool shed.

> Maybe you can comment on my rough plan for that project:
> - Graph converter, Tool (every format into every other including json)
> - individual converter to 'auto-convert' every datatype implicitly by
> Galaxy
>  - both are networkx based, so not sure that can be included in Galaxy
> Main, we need at least a new egg
> - write a dataprovider that provides json for every format to graphview
> (omitting the reconstruction of a graph, again in JS)

I'd think if you can parse it with networkx, you can pipe that through a
dataprovider to provide the d3 formatted JSON (which is what the
'node-edge' does).

> - enhance the graphview interface a little bit, some control elements,
> ideally an export function to SVG, PNG
> - add filtering to the graphview
> I must admit, that I haven't looked much into the details of the JS code
> of graphview but as far as I see its d3.js based and I hope the last two
> points are more or less easy with d3.js
The last should be fairly easy. The second-to-last is more difficult
(though on my list for the registry as a whole).

Unfortunately, d3 doesn't handle either right now well (mainly due to
browser technology).

The best soln's for SVG seem to involve either a round trip to the server
or asking the user to *right*-click a link a choose 'Save as'. In either
case, including a proper stylesheet for the SVG (or, in the future, a scoped
stylesheet <http://caniuse.com/#feat=style-scoped>) becomes an issue -
especially if it will be imported into a PDF, printed, or copied into Word,

PNG's will involve a round trip to the server and some library on that side
that can reliably and accurately render the SVG onto a bitmap (inkscape or
imageMagick(?)). There's also a small chance that a canvas library could be
used to render the SVG and serve it as a data URI without the round trip.

> Do you have any ToDo items on your list regarding graphview? Should I
> create a Trello Card for it?

Not at the moment. Please, feel free and thanks for doing it.

Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to