Interactive figures in sphinx/readthedocs?

[nvaytet]

Hi,

I was wondering if it was possible to embed the interactive figures in the sphinx documentation pages.

All the ipywidgets are visible and interactive in the doc pages (https://ipywidgets.readthedocs.io/en/stable/examples/Widget%20List.html).

I tried building my documentation with ipympl instead of the inline backend, but only the control buttons are showing up, not the figure:

instead of

with the inline backend.

I'm thinking in principle, the figure is just using some javascript to display it in jupyter, so it should also be possible to show it in the doc pages.
Many thanks for any help.

[martinRenou]

Indeed it does not work in docs currently, I would recommend using the inline back-end for now. We could try embedding a static plot in the docs. Just note that it will never be possible to use an interactive plot in the docs if you don't have a Python kernel responding to events on the server.

[nvaytet]

Hi Martin,

Thanks for the swift reply. I see, so everything is done on the kernel side.
Now that i'm looking at it again more closely, I can indeed see that the kernel is working when i'm panning/zooming.
And this is also the case for the classical notebook backend.

Ok, it's not a huge deal, I thought it would have been nice to be able to use a single backend for everything.
Right now, i'm having to juggle between 3 different backends: the nbAgg for the classical notebook, the ipympl for JupyterLab, and inline for the docs.

If you are interested (i know you guys at QuantStack like working with C++), we are working on a library for multi-dimensional arrays which is similar to xarray but with a C++ core under a python interface: https://scipp.github.io/index.html.
So it's also similar to xtensor but with the added labeled dimensions.

Cheers

[martinRenou]

Hey!

It looks interesting :) We also started to work on a similar package based on xtensor called xframe: https://github.com/xtensor-stack/xframe it is still at early development stage though.

[thomasaarholt]

Right now, i'm having to juggle between 3 different backends: the nbAgg for the classical notebook, the ipympl for JupyterLab, and inline for the docs.

Can you reduce this to just two by using ipympl for classical jupyter notebooks?

[tacaswell]

We have been dealing with this by putting an extra repr of the Figure in after you are done drawing to it (see https://github.com/bluesky/tutorials/blob/master/Hello%20Bluesky.ipynb which renders as https://blueskyproject.io/tutorials/Hello%20Bluesky.html). It is a bit of extra boiler plate (as you need to explicitly say "please show the figure here) but it means your notebooks will work in both cases.

When you repr theFigure, the output put into the notebook is a static png so you if make a figure and then in subsequent cells add / remove / change artists or the view limits etc you could tell a nice story of exploring the data in a static way and give the users who get a hold of a live kernel a live figure to work with.

[tacaswell]

attn @danielballan

[nvaytet]

Right now, i'm having to juggle between 3 different backends: the nbAgg for the classical notebook, the ipympl for JupyterLab, and inline for the docs.

Can you reduce this to just two by using ipympl for classical jupyter notebooks?

Yes, thanks for the suggestion. Currently, most of our users are using the classical notebook, and I have thus not yet managed to decide if it is better to use the matplotlib-maintained nbAgg and not add an extra dependency, or just rely on ipympl because it makes the code simpler.

So far, as it is not too much additional code, I'm keeping the nbAgg. In the future, if we start using JupyterLab more, I might change my mind.

[nvaytet]

Hey!

It looks interesting :) We also started to work on a similar package based on xtensor called xframe: https://github.com/xtensor-stack/xframe it is still at early development stage though.

Hi Martin,
Yes we looked at xframe also (actually, it was probably xframe I wanted to reference in my post above, instead of xtensor), and we decided it was still a bit too early in development to rely on it for our science program.
It would also have probably taken some time before we could incorporate changes such as event data (basically like a vector of arbitrary length vectors), physical units, and uncertainty propagation, all of which we needed from basically day 1.
The lazy evaluation is, however, a really nice feature that we are still missing.
We are keeping an eye on how things develop.
Cheers.