Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement ipywidgets and @interact support for jupyter #1930

Open
williamstein opened this Issue May 6, 2017 · 14 comments

Comments

Projects
None yet
4 participants
@williamstein
Copy link
Contributor

williamstein commented May 6, 2017

@jasongrout -- any comments here...?

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

@williamstein

This comment has been minimized.

Copy link
Contributor Author

williamstein commented May 6, 2017

Make sure to handle this: #486

@williamstein

This comment has been minimized.

Copy link
Contributor Author

williamstein commented Oct 13, 2017

Bug since everybody expects it to just work here.

@SylvainCorlay

This comment has been minimized.

Copy link

SylvainCorlay commented Apr 30, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

williamstein commented Apr 30, 2018

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

This comment has been minimized.

Copy link

SylvainCorlay commented Apr 30, 2018

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 comment has been minimized.

Copy link
Contributor

jasongrout commented Apr 30, 2018

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

This comment has been minimized.

Copy link
Contributor Author

williamstein commented May 1, 2018

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

This comment has been minimized.

Copy link
Contributor

jasongrout commented May 1, 2018

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

This comment has been minimized.

Copy link
Contributor

jasongrout commented May 1, 2018

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

This comment has been minimized.

Copy link
Contributor

jasongrout commented May 1, 2018

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

This comment has been minimized.

Copy link
Contributor

jasongrout commented May 1, 2018

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:

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:

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

@williamstein

This comment has been minimized.

Copy link
Contributor Author

williamstein commented May 1, 2018

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

@williamstein

This comment has been minimized.

Copy link
Contributor Author

williamstein commented May 2, 2018

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

This comment has been minimized.

Copy link
Contributor Author

williamstein commented Mar 28, 2019

Active work in progress here: #3717

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.