[IPython-dev] embedding js9 into a notebook

[Nicholas Bollweg]

You wouldn't want to eval yourself anyway... if you do it the notebook way
with display(Javascript()), you'll have access to a lovely element
variable, which is the cell output where you are right now.

Looking a bit deeper, I see all the dependencies, both frontend and backend.

Here's a notebook with my amateurish means of exploring the kinds of things
that will fail:
http://nbviewer.org/1259dd3bb7cef8988e92

It's going to be a pretty long road to make everything play nice, widget or
no. But hopefully this helps.

On Fri, Oct 2, 2015 at 10:29 AM Gijs Molenaar <gijsmolenaar at gmail.com>
wrote:

> Hi Nicholas,
>
> Thanks for your answer!
>
> meanwhile I found out why pushing some javascript to the browser using publish_display_data
> doens't work. It is related to this issue:
>
> http://stackoverflow.com/questions/4670805/javascript-eval-on-global-scope
>
> When I load the javascript files using `$.globaleval()` I get everything
> to work. Not sure how to make that work with an IPython notebook though.
>
>
> 2015-10-02 16:24 GMT+02:00 Nicholas Bollweg <nick.bollweg at gmail.com>:
>
>> Started a draft earlier, lost it.
>>
>> js9 looks very cool! I'd love to see it integrated!
>>
>> I would recommend doing an nbextension and wrapping your view in a
>> widget, packaged up as a python module. Then you either have to tell the
>> user to install the files to the magic location, or do it for them (as
>> qgrid, with its nbinstall) based on something they do.
>>
>> Though they are not the same thing, the big advantage to nbextensions and
>> widgets are:
>>
>>    - widgets: interactive integration with all the other widget things:
>>    layouts, controls, etc.
>>    - Some Day being able to use your front end work with another kernel
>>
>> When integrating with the notebook front end from python "simply", a
>> higher order pattern than publish_display_data is:
>>
>>
>> *def show(data):   display.display(Javascript("..**.data..."))*
>>
>> Every time you want to change something, you call show. If you want to
>> have the frontend do something to the backend, you do something like
>>
>> *IPython.kernel.execute("something")*
>>
>> Eventually, you will end up reimplementing most of what widgets do.
>>
>> With widgets,
>>
>>
>> *class SomeWidget(Widget):   _view_module = Unicode
>> ("nbextensions/extension/file"*
>>
>> *)   _view_name = Unicode ("SomeView")   Data = SomeTrait()*
>>
>>
>>
>> *x = SomeWidget() display.display(x) x.data = data*
>>
>> You can work with the widget instance as a normal python object... But it
>> has a secret life up in the browser, and you don't have to worry about
>> state, which is huge. Now your view/backend is part of the larger widget
>> ecosystem, and other widgets can be linked to it without any additional
>> integration work, and you're really pushing
>> All that being said, this is not as easy as it could be. The issue arises
>> from "the notebook" as the user perceives it, actually being:
>>
>>    - the kernel: do compute
>>    - the server: provision compute, serve static assets
>>    - their code and data
>>
>> The single user, native kernel, local install experience has suffered
>> somewhat from the needs of the distributed, multi-user, multi-kernel
>> experience. In the case of javascript, the kernel doesn't even know it's
>> running a notebook (could be running shell or qt... or whatever).
>>
>> So we're stuck right now with:
>>
>>    - install your backend package into the kernel
>>    - install the extension into the server
>>
>> Here is an exhaustive issue describing some of the issues (with
>> pictures!):
>> https://github.com/jupyter/notebook/issues/116
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> https://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
>
> --
> Gijs Molenaar
> http://pythonic.nl
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20151002/9453259d/attachment.html>