This is a post to generalize the discussion from this pull request.
The main question: what kinds of strategies can we use to send a plugin some information and then generate a plot with output from the plugin?
We could put the burden of plotting on the plugin itself, but it would be repetitious to have every plugin using its own plotting software and generating plots on its own.
Since we are planning on making VTK a dependency of Avogadro2, I think it makes sense for us to use VTK to generate the plots, and come up with some kind of method for a plugin to communicate to Avogadro2 what to plot and how to plot it.
We could potentially make some kind of general API in Avogadro2 with which plugins can generate plots. Or perhaps the plugin could send plotting information to Avogadro2 via json-rpc.
The method of communication may also differ depending on how the plugin is designed (i. e., does the plugin consist of python scripts, shared object libraries, etc.).
Let me know what you all think!
1 Like
I think we definitely want to offload plotting to Avogadro.
One alternative to VTK, that I’ve considered is Chart.js, which already has QML bindings, so it’s fairly lightweight.
https://github.com/jwintz/qchart.js
The main question, as you mention, is how to handle sending data to the plotting code. One reason I like the Chart.js adaptation is that the JSON representation is fairly compact:
http://www.chartjs.org/samples/latest/
What I’d like to do is:
- Decide on what code will do the plotting (e.g., VTK in your pull request)
- Decide on the simple use cases (e.g., plotting a line chart for spectra)
- Make sure the solution can be extended to more complex use cases (e.g., band structure diagrams)
My feeling is that the most common use case is a plugin returning a set of data to plot, likely with some sort of labels (e.g., mouse-over on this point to see it’s the <100> peak).
The interaction use case is a bit more interesting - the user clicks on part of the plot, and something happens, e.g., you plot multiple geometries from an optimization or multiple conformers, and the UI will change the current molecule accordingly.
I think it would be easy to add a wrapper on the VTK charts to accept JSON too, at some level it doesn’t matter what charting library you use if there is a JSON API that takes care of plotting. Slicer spent years trying to get DOM-based charting libraries to scale, and had many issues before deciding to switch to the VTK charts, although I doubt we will ever have that many points to plot.
We did some work on D3 charts with 3DMol.js in a web application, it would be great to mirror some of that in Avogadro. I know the paths to generate signals for the VTK charts if we wanted to do that. The vtkTable structure would easily map to JSON - each column has a name, and then a set of values in a single type. I think starting with a few simple use cases like the PR you made would be great, and we could build up from there.
1 Like
For what it’s worth, there’s a D3-QML integration post here:
I agree that we’re unlikely to have millions of data points (famous last words) so I think the back-line technology doesn’t matter much.
- VTK - if we’re going to finish VTK integration (e.g., volumetric rendering) the charting comes “for free” as long as we can map a reasonably easy JSON like the JS charting options
- Chart.js - easily gives interactive animation
- D3.js - ditto
I think the pro for the JS+QML options are the well-documented JSON interfaces…
Happy to play with options, if we decouple it with JSON even better. I am working on code to bring volume rendering in, at which point the extra time to compile charts is minimal. I know the VTK charts code really well, and actively use it in a few other projects. For my part, I was planning on working on getting volume rendering working, and the color-opacity transfer function widget I would like to reuse from Tomviz is VTK chart based too.
Whatever we use I like the idea of simple JSON to communicate the data, and that would make it easier to substitute in other alternatives in the future too.
I’m thinking of simple JSON for the data (e.g., like Charts.js datasets) because it makes it really easy to return from Python scripts. For C++ code like Patrick’s, there can be a full-featured API, but I’d love to see a quick-and-dirty approach that allows a Python script to optimize a molecule and plot the energy as a progress dialog, etc.