Blocking cell execution waiting for Widget interaction #311
Description
Hi all,
I am interested in blocking further cell execution in a Jupyter notebook until some sort of widget interaction has occurred. For instance, letting a user perform a "cell -> run all" command, then displaying a dropdown widget in one cell, and blocking in the next cell until the user has selected an option from that dropdown list.
In a regular notebook setup, widget changes (comm_msg over zeromq) won't be picked up by the kernel because it's blocking until the cell is completely executed. If an Asynchronous Loop is involved, then all cells will be executed (from the "cell -> run all") command immediately if they aren't written in an async fashion.
One option is to override the kernel.shell_handlers functions to 'capture' the execute_request messages coming in on the stream while letting the comm_msg events go through, then to 'replay' the execute_request messages after the fact. If I go with that pattern (example, how do I make the output show up in the output cells for the original input cells instead of all in a single cell where the 'replay' happens?
A second option is to have the ipykernel listen for execute_request and comm_* events on different streams. There's been discussion of that idea (@dsblank @AlexTugarev #65, @jasongrout jupyter/jupyter_client#285), but it doesn't look like the issue has moved forward. I don't understand the entire front-end/back-end system to know how significant that change would be. Is this issue a non-starter (#302)?
Thanks.