[IPython-dev] 'Stateless' interact: a widget experiment
Damián Avila
damianavila at gmail.com
Mon Jul 27 09:42:57 EDT 2015
Thanks Thomas! Some comments below...
>This has some key benefits: as regular Javascript output, the widgets are
persisted as part of the notebook. Their state is not saved for now (more
on that below), but when you reopen it, the widgets will be in their
starting position, with the initial output shown. If they can connect to
the kernel-side part, they will be enabled and usable; if not, they'll show
up disabled. It should even be possible to show them (disabled) on
nbviewer, but that's not working yet.
Super!
>Things it doesn't do yet but could fairly easily:
>- Widgets other than sliders
>- Display of output other than plain text
>- Widgets visible on nbviewer
>- A nicer Python API (decorators, widget abbreviations, etc.)
+1
>Things I'd like that may require some changes in Jupyter:
>- Persistence of widget state: I think the key here is a way for JS output
areas to get a handle on the output object that will be stored in the
notebook document. Then they could store this kind of info in the output
metadata.
I like the idea to store the info in the output metadata, feels like the
"natural" space for this implementation...
>- Better handling of kernel disconnection/reconnection: e.g. at present,
it disables the widgets on the kernel restarting event, but if I have the
notebook open in two browsers, the event only fires in the one where I
asked for a restart. I'm not sure exactly what happens with comms - it
doesn't look like they're closed when the kernel disconnects or restarts.
>- Not dumping duplicate JS in the notebook: we've discussed this before.
There's a chunk of JS that I send each time an interact() displays, and
it's only going to get longer as this project expands. It would be good to
store just one copy of this. I would like it to be saved as part of the
notebook, though, so the widgets can be shown without involving the kernel.
+10 as well, I also saw this problem about dumping duplicate JS in other
contexts. Would be nice to finally solve it.
>- Showing widgets in untrusted notebooks: this would require the JS to
construct them to be installed as an extension (or part of the notebook) so
we can run that without security issues. I'd probably then use display_json
to put widgets on the page.
Yep, it could be an option installing it as an extension...
>Currently, there's no way to update widget state from code in the kernel.
I'm not sure that this really makes sense, since there can be multiple
clients with independent states, but it would probably be possible to
broadcast an update message to the connected clients if we did want that.
I don't like the idea to break multiple client independent states, but it
would be probably nice to have it from broadcasting purposes, which is
probably an important use case.
>I want to emphasise this is very much a *prototype*, not something you
want to use today. I think it's worth exploring because it feels like a
much simpler system than synced-model widgets, and it has the potential to
give us an easier story around persistence. It will never do all the things
you can do with synced-model widgets, and that's quite deliberate.
I agree with you that this is something to continue exploring. Thanks for
sharing it!
On Mon, Jul 13, 2015 at 5:21 PM Chris Colbert <sccolbert at gmail.com> wrote:
> On Mon, Jul 13, 2015 at 4:05 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>
>>
>> Currently, there's no way to update widget state from code in the kernel.
>> I'm not sure that this really makes sense, since there can be multiple
>> clients with independent states, but it would probably be possible to
>> broadcast an update message to the connected clients if we did want that.
>>
>>
> As a simple straw man case, how would this handle updating a label whose
> text is generated based on a computed model parameter when that model
> parameter changes?
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
--
Damián Avila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150727/46100b32/attachment.html>
More information about the IPython-dev
mailing list