If I could step in here some months later, and move to a higher level of conversation, I think that there are several levels of engagement with Jupyter that we could contemplate. For example, we could display a notebook, graphics output and all, in a separate pane. ViewRendered does that pretty well. But there's not much point, because it's static and we can't change the notebook. The notebook can already be viewed in a web browser, and looks better or at least it can be larger.
To be useful, I think the minimum engagement level is: 1. Be able to import a Jupyter notebook into a Leo tree, and have it look like a normal Leo tree (possibly with some @jupyter-notebook nodes). 2. Leo cells would not have to have code outputs necessarily, just static images and text. 3. Changes to the Leo tree can be exported back to the Jupyter notebook, which would then work right in a Jupyter application. Anything less than this, I don't see as worth spending time on. At a higher level of engagement, we would add the ability for code output and graphics to be captured and exported to the notebook. I think that Ed may be thinking about some version of this, if I'm understanding him right. At a higher level yet, a Jupyter server could run in Leo's namespace and Leo could interact with its API directly. This would let us have dynamic graphics that the user can interact with, just as Jupyter notebook has already. For example, I'm thinking about Holoview interactive graphs. I believe that the graph has to be able to communicate with the server for this to work (though I'm not completely sure). As a fallout of this work, it would be useful if the machinery for putting a plot in a cell, putting code output in a cell, etc., could be abstracted so that in the future it would be easier to plug in something else besides a Jupyter Notebook with having to reinvent and re-code everything. I wonder if using QML widgets would make this easier...and if that would be feasible with Leo's current design. On Tuesday, January 10, 2017 at 2:55:34 AM UTC-5, Edward K. Ream wrote: > > In this post, I'll discuss how Leo can integrate with IPython and Jupyter > notebooks so as to become a premier literate *computing *environment, as > Offray uses the term. > > This is a design document. I'll focus only on what the user sees and > experiences, not on how Leo might actually get the job done.* tl:dr:* > Read the summary. > > *IPython and Jupyter will remain essentially unchanged* > > I assume that both IPython and Jupyter will not change in their essential > qualities. That is, IPython and Jupyter are *fixed* (constant). In > particular, I assume that for the foreseeable future that Jupyter notebooks > will be a *linear* list of cells, not a tree of cells. In any case, the > following design would not change much if Jupyter notes ever *do* support > trees of cells. > > *Implications* > > 1. As a direct consequence of this assumption, only Leo will explicitly > deal with outlines. > > 2. There must be some way of converting (parts of) Leo outlines to a > *list* of .ipynb files. There is considerable room for creativity in this > conversion process. That is, we want to keep tree-to-notebooks process in > the back of our mind as we think about Leo trees. > > *The Jupyter design* > > The jupyter notebook handles cells in a simple, intuitive manner as > follows: > > 1. Running a code cell produces output *in that cell*. That is, the > output is attached to the cell itself, not in a Qt popup window. > > 2. It's possible to switch the types of Jupyter cells from a dropdown > menu. The cell types are Code, Markdown, Raw NB Convert and Heading. > > 3. There are Jupyter commands to run some or all cells, and to insert, > delete and move cells. > > *A preliminary design* > > Imo, we probably want similar (or improved) behavior in Leo cells: > > - It should not be necessary to open a view-rendered window to see the > output of a cell. > > - Cells should show the In and Out numbers, just like in IPython or > Jupyter. > > - Leo directives will indicate the type of cells. Some of these > directives will apply to descendant nodes. > > - Leo will provide commands to run all cells, selected cells, selected > subtrees and marked cells. > > - Existing Leo commands will suffice to insert, delete, move, clone, > promote and demote cells. > > *New directives* > > *@jupyter-notebook*: explicitly denotes a notebook. All descendants are > IPython cells. Useful when converting a Leo outline to one or more Jupyter > notebooks. > > *@cells*: All descendants are IPython cells. > > *@cell*: A single IPython cell. > > Within a cell, @language denotes the type of cell. > > @language markdown denotes a Jupyter Markdown cell. There probably is not > great need for Jupyter Heading cells: they may come free with Leo's outline > structure. > > @language python (or julia, or r, etc) denotes a code cell. > > *Behavior* > > There is lots of room for experimentation re behavior and rendering. In > general, we want cells to work just like the corresponding Jupyter cells, > but enhanced, when possible, by Leo's outline structure. > > For example, the rending of @markdown cells might include the rendering of > all descendant @markdown cells, thereby making Jupyter Heading cells > unnecessary with Leo itself. Otoh, Leo will "reconstitute" Heading cells > when exporting @jupyter-notebook trees. > > > *Summary* > 1. New Leo directives will designate subtrees as containing IPython > *cells*. Such cells will look and work like individual IPython cells. > They will show In and Out numbers, and will show output directly, without > the need for a viewrendered pane. > > 2. Leo's existing @language directives will indicate the type of cell. > Such directives could affect which Jupyter kernel evaluates Code nodes. > > 3. Wherever possible, Jupyter commands and cells will be enhanced by Leo's > outline structure. For example, the rendering of an @markdown tree may make > Jupyter Heading cells unnecessary. > > 4. Converting an outline to one or more .ipynb files might allow easy > cross-file references in the resulting Jupyter notebooks. A > table-of-contents notebook would likely be easy to create. > > All comments welcome. > > Edward > > P. S. To prepare for this post, I have carefully read all the comments and > references in the Leo + PlantUML workflow > <https://groups.google.com/forum/#%21topic/leo-editor/hNkQG5n6X6M> > thread. Naturally, I may have misunderstood something. Please correct me if > so. > > EKR > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
