implement ipywidgets and @interact support for jupyter

[williamstein]

@jasongrout -- any comments here...?

Despite this not being in the initial release, it is still high priority.

[williamstein]

Make sure to handle this: #486

[williamstein]

Bug since everybody expects it to just work here.

[SylvainCorlay]

@williamstein @haraldschilly we may be interested in giving it a stab over the summer.

Why do you think it would be insanely hard to make a widget manager specialization for the cocalc notebook?

[williamstein]

Why do you think it would be insanely hard to make a widget manager specialization for the cocalc notebook?

One issue is that it must be properly multi-user. Even the semantics of that are not totally clear. The actual implementation might be similar to how multiple cursors are broadcast now in cocalc, but I'm not sure.

Another issue, once the foundations are in place, is that there are dozens and dozens of controls to implement.... and maybe their exact behavior isn't totally specified in docs?

I would love some help on doing this project though. I'm definitely going to get it done this summer or before, and any help (even a regular weekly meeting during the project) would be awesome!

[SylvainCorlay]

Another issue, once the foundations are in place, is that there are dozens and dozens of controls to implement.... and maybe their exact behavior isn't totally specified in docs?

On that subject, I don't think that it would be a good idea to re-implement the controls. A lot of custom widget libraries are built upon ipywidgets and are based on the base widget classes.

(ipyvolume, pythreej,s ipyleaflet, nglview, beakerx, bqplot) and many many more.

One issue is that it must be properly multi-user. Even the semantics of that are not totally clear. The actual implementation might be similar to how multiple cursors are broadcast now in cocalc, but I'm not sure.

Yes, I totally agree. We have had some discussions about this, which have not gotten beyond drawings on a whiteboard.

I would love some help on doing this project though. I'm definitely going to get it done this summer or before, and any help (even a regular weekly meeting during the project) would be awesome!

Great! I would love to see more frontends support widgets, so I am happy to help. There might be some simplistic models for multi-user support that we could start with, such as a single use holding the right to modify the state while all other can only see it, before we figure out the right approach.

[jasongrout]

This would be awesome to see. The big hurdle from an design point has been the semantics of what multi-user means in the context of an interactive widget. Of course, the big technical hurdle (and big hurdle to experimenting with designs) has been the lack of a good multi-user system like what cocalc has already implemented.

[williamstein]

If I don't have to reimplement the controls, this will be much easier. Can you point me to a link that documents the API of the controls themselves (or just some entry point to the code or where they are used in JupyterLab?).

Jason, let's do something in CoCalc so we can at least have something implemented, and get past that hurdle. It might feel wrong, in which case I can redo it...

[jasongrout]

ipywidgets uses these messages to communicate between the frontend and backend to create controls and sync state between the frontend and backend: https://github.com/jupyter-widgets/ipywidgets/blob/master/packages/schema/messages.md#widget-messaging-protocol-version-2. In Jupyter notebook and JupyterLab, these messages are transmitted via the comm framework.

The state that is synced depends on the control - here is the synced state definition for each control included with ipywidgets 7.2: https://github.com/jupyter-widgets/ipywidgets/blob/master/packages/schema/jupyterwidgetmodels.v7-2.md.

[jasongrout]

The actual code for the controls is in the base and controls packages, except for the output widget, which is specialized to each frontend.

[jasongrout]

Some very incomplete experiments with starting to write some of the controls using react is at jupyter-widgets/ipywidgets#1796 - the logic for the controls would be much simpler in that case. However, I haven't had time to push through with finishing that.

[jasongrout]

Have you implemented the notion of comms (http://jupyter-client.readthedocs.io/en/latest/messaging.html#custom-messages)?

Once you have the notion of comm objects, probably the easiest path is to implement a new cocalc-specific widget manager by subclassing the abstract base class at https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/packages/base/src/manager-base.ts#L137, and in particular the abstract functions:

• https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/packages/base/src/manager-base.ts#L154
• https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/packages/base/src/manager-base.ts#L513
• https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/packages/base/src/manager-base.ts#L528
• https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/packages/base/src/manager-base.ts#L535

The widget manager is responsible for setting up a comm target for requests to create a new widget, managing creating new comms, and also responsible for displaying a particular widget - basically the manager is responsible for interfacing between the widget js code and their environment.

You can see examples in the various widget managers we ship, probably the simplest of which is the html widget manager that is responsible for displaying widgets on an arbitrary web page:

• html widget manager, for putting widgets up on an arbitrary html page: https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/packages/html-manager/src/htmlmanager.ts

More specific widget managers are the classic notebook and JupyterLab ones, which are very specific to the environments:

• classic notebook (and also the most complete widget manager): https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/widgetsnbextension/src/manager.js#L76
• JupyterLab (which still is incomplete in some ways): https://github.com/jupyter-widgets/ipywidgets/blob/766cad54a47c07520e9d695534c4664c3391e7ec/packages/jupyterlab-manager/src/manager.ts#L80

[williamstein]

Thanks for the links. No, I haven't implemented comms yet...

[williamstein]

by subclassing the abstract base class

By the way, you'll be happy to hear that we are rewriting (key parts of) CoCalc in Typescript (instead of CoffeeScript). That will help a little with longterm compatibility between cocalc and jupyterlab.

[williamstein]

Active work in progress here: #3717

[williamstein]

Done!

More precisely, something pretty usable is now live, though I'm sure there will be some bugs, which will be new issues. I'm closing this.