[IPython-dev] [iPython-dev] thoughts on the notebook, alternative front-ends and remote editing

Matthias Bussonnier bussonniermatthias at gmail.com
Thu Mar 5 16:16:36 EST 2015


Hi Jared, 


Please to see that, looks nice to see alternative front ends !

A few inline/comments questions.

Le 4 mars 2015 à 23:29, Jared Forsyth <jared at jaredforsyth.com> a écrit :

> This might be a good time to let y'all know about the alternative front-end I've been building for ipython :)
> Although it's probably better described as a "life manager / notebook" that happens to have first-class support for ipython integration.
> 
> Some important aspects:
> UI
> - tree-based structure (think workflow)

We are considering "tree" for notebook, but we are more targeting "implicite" tree structure base on the header level. 
we used to have worksheet.  Manipulating tree was too complicated in our opinion with respect to the user interface model. 

I'm curious of wether you have feedback on that your users perspective, and aslso from developpemetn point of view. 

> - highly optimized for keyboard navigation
> - multiple display modes possible (including a mindmap view)
> - searchable
> - multi-paned (arbitrary paning)
> - pop out the output of a node into a separate window

I had difficulties finding out how to get "out" of this view, or even understand during the first second it was just a view. 
I think one need either an animation, or a visual indication. 
Adobe Illustrator have this nice think when you edit a subnode that the siblings are still roughly there but really discreet/translucent
 in the background

> - multiple note types (markdown, code, todo-item, list-item, embedded image)
> - import/export to .ipynb and several other formats

Nice, are you using nbconvert. 
Are you using IPython 2,x or 3.x ? I'm not sure you are aware that we have ~30 languages supported. 
(https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages) 

Though you seem to have rust we don't have. 

Any comment on how easy/missing features of our protocol ? 


> - visual indication that cell is "dirty" -- the contents have been changed since last evaluation

I'm curious about the semantics, we don't have that in IPython because we did not agreed on when something would be "dirty"
or clean.

> 
> Architecture
> - browser-based, but offline-first (no server required)
> - connects to an ipython server, or a clojure repl, or an in-browser js kernel

> - *everything is always saved* to in-browser storage, with optional synchronization to google drive or a github gist (for multi-user, multi-device)

Do you have an abstraction layer? Are you interested in realtime implementation ? could we share some js implementation/protocol maybe ? 

> 
> I've managed to get together a tutorial for ipython and a  general navigation tutorial, and more docs are coming soon.
> 
> I'd love to get your feedback!

Thanks for what you  did ! Hopping to work with you in the future. 


Some response to other mails. 

I'm also looking forward to use reach or other equivalent library. 
Right now I'm playing with real-time api and what abstraction are needed
in the notebook to support many API.
It would be great to draft compatibility of API and sharing libraries. 
That will probably be easier once we split our repo  in multiple sub-repos. 

To NIck, 

I guess the final API will not be google drive and that you will have one more layer of indirection. 
Having people testing many framework is really nice and would hall us getting the right api. 
I do thing that for now GDrive is really nice as it allows custom and easy sharing of notebook, 

We already have a lot of complains of too many dependencies, and drive is one of the things that most of the time :

1) does not require you to create yet another account 
2) integrate with sharing.
3) allow to ship an extension with no deps. 

Would love to see experiment with mithril, and other. 
The current maintenance of  IPython (and traffic on ML these last day) does not give me enough time
to investigate many framework. 

Also the goal of Jupyter is to make organisation and working groups for things like that, 
so looking forward to meetings. 

Cheers, 
-- 
M



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150305/757c469c/attachment.html>


More information about the IPython-dev mailing list