<div dir="ltr"><div><div><div>Ondrej,<br><br>This seems very cool. <br><br></div>I have been working toward what seems like a similar goal, but from a different angle.<br><br></div>My aim is to have the interactivity and ability to control parameter values and re-execute the code be an attribute of the codecell itself, rather than a consequence of the particular code run within the codecell.<br>
<br></div>I approached the problem this way for a couple of reasons:<br><br>My primary focus is on using the notebook as a publication mechanism, specifically for publishing computational science and statistical analysis based research.  Imagine a journal article involving code/output pairs where the reader can alter the computations being done (e.g. change the bandwidth on a smoothing algorithm) and immediately view the affect that change has on the results being discussed.  <br>
<br>It is cleaner to not have the code to render the widget appear in the code cell, particularly when the purpose of the widgets for my use case is to allow viewers to explore the parameter space <i>without</i> necessarily understanding the code or how to modify it.<br>
<br>Related to the point above, if the interactivity comes from the cells themselves, all code used in the analysis itself can be placed within the notebook unchanged, rather than needing to be modified to support the interactivity (e.g. made into functions which used as callbacks, etc), giving a more direct view of exactly what the analyst did.<div>
<br>For this reason i am working on a interactivecodecell subclass of code cells which has associated with it a set of widgets definitions. Each of these widget definitions is associated with a variable used by the code. When such a cell is rendered, UI components appear above the codeblock. These UI widgets then temporarily alter the code to reflect the chosen parameters and rerun it to generate fresh output.<br>
<br></div><div>I have a very early proof of concept on github which I can link to if desired but its conflated with a bunch of other stuff I&#39;m doing with the notebook and isn&#39;t in any sort of usable state yet.<br>
<br></div><div>I&#39;d love to hear what people think about these different approaches.<br><br>Sincerely,<br></div><div>~G<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 9, 2013 at 2:14 PM, Ondřej Čertík <span dir="ltr">&lt;<a href="mailto:ondrej.certik@gmail.com" target="_blank">ondrej.certik@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jake,<br>
<br>
Yes. And also the same thing on the JS side --- currently I am<br>
populating the global name space with global functions, which is not<br>
good. Ideally there would be some nice javascript class/object and<br>
then we&#39;ll attach the instances into the global IPython object.<br>
<br>
Also, this is just a demo of exactly one slider to show that the user<br>
interface can be a nice simple Python code. I actually need more GUI<br>
elements. So I think that something like Traits UI:<br>
<br>
<a href="http://code.enthought.com/projects/traits/docs/html/index.html" target="_blank">http://code.enthought.com/projects/traits/docs/html/index.html</a><br>
<br>
would be the way to go.<br>
<br>
Those are all questions that the IPython developers should provide<br>
feedback on, so that I can do something that could be merged.<br>
<br>
Ondrej<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Jun 8, 2013 at 3:43 PM, Jacob Vanderplas<br>
&lt;<a href="mailto:jakevdp@cs.washington.edu">jakevdp@cs.washington.edu</a>&gt; wrote:<br>
&gt; Very cool!<br>
&gt; One comment: I think that rather than passing python_var an explicit name,<br>
&gt; it might be better to populate a dict in the IPython namespace with the<br>
&gt; names of objects that need to be accessed by the javascript.  i.e., within<br>
&gt; the slider init function, you could have something along the lines of:<br>
&gt;<br>
&gt; ```<br>
&gt; import IPython<br>
&gt; if not hasattr(IPython, &quot;_interactive_elements&quot;):<br>
&gt;     IPython._interactive_elements = {}<br>
&gt;<br>
&gt; key = random.randint(0, 1E7)  # or use some sort of hash function<br>
&gt; IPython._interactive_elements[key] = self<br>
&gt; self._python_var = &quot;IPython._interactive_elements[%i]&quot; % key<br>
&gt; ```<br>
&gt;<br>
&gt; That would keep track of the object names in the background.<br>
&gt; Other than that, I like the implementation!<br>
&gt;    Jake<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Jun 8, 2013 at 12:25 PM, Ondřej Čertík &lt;<a href="mailto:ondrej.certik@gmail.com">ondrej.certik@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; I have implemented the slider widget here:<br>
&gt;&gt;<br>
&gt;&gt; <a href="http://nbviewer.ipython.org/5736280" target="_blank">http://nbviewer.ipython.org/5736280</a><br>
&gt;&gt;<br>
&gt;&gt; &gt;From the cell [2] you can see how it is used, it&#39;s trivial. I suggest<br>
&gt;&gt; you run this in your local notebook, because the cell output is not<br>
&gt;&gt; visible in the nbviewer. Also you need Chrome, as Firefox doesn&#39;t<br>
&gt;&gt; support the HTML 5 slider and I haven&#39;t figure out how to use jquery&#39;s<br>
&gt;&gt; slider yet.<br>
&gt;&gt;<br>
&gt;&gt; I read your roadmap, and my understanding is that the plan is to start<br>
&gt;&gt; developing this in December. Unfortunately I needed something now, so<br>
&gt;&gt; I wrote the above.<br>
&gt;&gt;<br>
&gt;&gt; I have already tested it for rotation of a 3D visualization using VTK<br>
&gt;&gt; 6 in ipython notebook (offscreen rendering) and it works great.<br>
&gt;&gt;<br>
&gt;&gt; What is your plan and actual ideas how these widgets should be<br>
&gt;&gt; implemented?<br>
&gt;&gt; Is there a reason why work on this cannot start now? I&#39;ll be happy to<br>
&gt;&gt; help with this<br>
&gt;&gt; and send PRs.<br>
&gt;&gt;<br>
&gt;&gt; If I recall correctly, you wanted to implement the widgets using the<br>
&gt;&gt; IPython implementation of traits?<br>
&gt;&gt;<br>
&gt;&gt; Ondrej<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; IPython-dev mailing list<br>
&gt;&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt;&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; IPython-dev mailing list<br>
&gt; <a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
&gt;<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Gabriel Becker<br>Graduate Student<br>Statistics Department<br>University of California, Davis<br>
</div>