On Wed, Mar 23, 2016 at 4:56 PM, Offray Vladimir Luna Cárdenas < [email protected]> wrote:
Here is something I wrote 3+ years ago about this idea (without > proof-reading and a worse English at that time): > > [1] > http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html > I think I agree with everything you said above. Indeed, the exciting thing about the new Leo relationship with IPython is that Leo becomes a natural tool for writing longer Jupyter documents. There are many tweaks that can be done to both the importer and the importer: - Split incoming cells at heading s. - Automatically import changed .ipynb files on save. - Save "hidden" data in @ignore trees, ignored by the exporter. - One-key open notebook in Jupyter. This can all be done with very little work. In other words, Leo becomes a superior authoring environment for Jupyter notebooks. and here is something I wrote a year about how to explore this idea of > programmable DOM + Live Interactive nodes on Pharo/Smalltalk instead of > python > > [2] > http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html# > > but Leo and IPython were not malleable enough, without deep understanding of their inner workings and/or by combining several technologies: python, qt, xml, json, javascript, html, zeromq, server programming, client programming, etc. That's pretty much solved now. It's easy to install Jupyter anywhere. Once that's done integration with Leo is (or soon will be) very easy. > I don't know if a Qt object could be complex enough to render small parts > of HTML or code (markup or python) inside a Leo node, but I think that > Leo's DOM and computing model its a lot richer that the one in the IPython > notebooks, while code completion, live markup and HTML rendering are better > in IPython that in Leo. > I would say that today is the second most important day in Leo's history. The first was realizing that I could use the MORE outliner as a prototype for Leo. Similarly, today we see that IPython (Jupyter) and Leo can *easily and naturally* work together. Leo is great for organization. Jupyter is great for rendering, sharing and security. > So keeping the Leo outlining experience while giving each node the > interactivity of IPython would be a far better interesting approach. > I don't think it's wise to try to outdo IPython. And I don't believe there is a great need to do this. There is another new direction I am considering, which may be the last part of the puzzle. I call it split nodes, and I'll discuss it in another thread. Edward -- 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.
