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

Design philosophy of ipywidgets wrt same-kernel collaboration #1881

Closed
sjdv1982 opened this issue Dec 22, 2017 · 4 comments
Closed

Design philosophy of ipywidgets wrt same-kernel collaboration #1881

sjdv1982 opened this issue Dec 22, 2017 · 4 comments
Labels
resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@sjdv1982
Copy link

sjdv1982 commented Dec 22, 2017

Currently, same-kernel collaboration is not working smoothly with ipywidgets.
I start a notebook session and enter the following cell:

import ipywidgets
ipywidgets.IntSlider()

When I modify the cell, embed the widget state, and save the notebook, the widget will show up when I load the notebook URL in a different browser.
In the new notebook session, the widget will modify the kernel value. However, the widget in the two sessions are no longer in auto-sync with the kernel: in each session, I have to press F5 to see any updates in the kernel value that were effectuated by the other session.

I am not sure if this is a bug or a design decision. This discussion seems on-topic, but mostly talks about security and locking, which I don't care about. In my case, in each notebook session, the code cells will be hidden from the user and only the widgets are being modified.

I am thinking of rolling my own interactive widget implementation (where the kernel simply launches a websocketserver, bypassing Jupyter completely). But if it is simply an ipywidgets bug, I won't try to re-invent the wheel.

@jasongrout
Copy link
Member

See also the relevant discussion at jupyter/jupyter_client#263 and #1218. Basically, a change in the Jupyter protocol is the cleanest way to handle this.

@sjdv1982
Copy link
Author

OK thanks for the comment. So it's essentially a known bug.

@sjdv1982
Copy link
Author

sjdv1982 commented Dec 23, 2017

After some more experimentation:
Setting widget.value directly from the kernel does synchronize to all connected browsers. So the problem can be fixed by attaching an observer to each widget inside the kernel. However, setting widget.value from within an observer does not work: it is either swallowed or causes a recursive loop. The browsers can be notified directly, though, using send_state. The following code works:

import ipywidgets
w = ipywidgets.IntSlider()
w.observe(lambda d: d["owner"].send_state("value"), names=["value"])
w

@jasongrout
Copy link
Member

Yes. A communication from the kernel to the frontend goes to all frontends. What is missing right now in the underlying Jupyter protocol is a mirroring of communication from a single frontend back out to all frontends.

What you're seeing with setting widget.value in an observer is that since the widget value didn't change, there is no communication with the frontend.

Can we move this conversation on #1218? We like to keep the conversation about an issue consolidated on one issue ticket so it's easier to track things. I'll close this issue and let's move the conversation over there.

@jasongrout jasongrout added this to the Reference milestone Dec 23, 2017
@github-actions github-actions bot added the resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Feb 9, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

No branches or pull requests

2 participants