[IPython-dev] [iPython-dev] thoughts on the notebook, alternative front-ends and remote editing
Jared Forsyth
jared at jaredforsyth.com
Thu Mar 5 17:01:44 EST 2015
To those points (in addition to my comments on the issue thread):
- *editor: *I think the editor should continue to be codemirror -- let it
do what it is good at. I use codemirror in Notablemind, and the interop
works just fine. I'd be happy to spin off my react-codemirror component
into a separate package if that's helpful
- *output areas: *large binary blobs are no problem for react, as long as
you're careful about things. Again, notablemind (rendering ipython outputs)
has no problem
- *widgets: *embedding arbitrary widgets within a react component is super
simple :). If widgets are written in react, all the better, but that's not
necessary.
On Thu, Mar 5, 2015 at 12:17 PM Kester Tong <kestert at google.com> wrote:
> Jared,
>
> can you let us know (here or in
> https://github.com/ipython/ipython/issues/7784) a bit about your
> experience with React. I've found it very easy to use but powerful, and it
> seems to play nicely with other frameworks. Other people have raised
> concerns about performance (e.g. Atom moved away from React for performance
> issues). I can identify 3 areas that might need to be handled outside
> react: the text editor, output areas (that can contain large binary blobs)
> and widgets (which I don't know a lot about). I think these can probably
> be solved simply by having React components that wrap some other code, and
> don't try to maintain state using React. But you have a lot more knowledge
> of this than me.
>
> Kester
>
> On Thu, Mar 5, 2015 at 2:07 PM, Jared Forsyth <jared at jaredforsyth.com>
> wrote:
>
>> ++for react. That's what the UI for Notablemind is written in, and makes
>> state management awesome. It also makes things like rearranging cells
>> trivial.
>>
>>
>> On Thu, Mar 5, 2015 at 9:36 AM Kester Tong <kestert at google.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> I'm part of the Google team that is working with IPython on realtime
>>> collaboration and notebook redesign. I was also one of the developers on
>>> the coLaboratory project, where we implemented a Notebook front end using
>>> the Google Drive realtime API (see
>>> https://github.com/jupyter/colaboratory or
>>> https://chrome.google.com/webstore/detail/colaboratory-notebook/pianggobfjcgeihlmfhfgkfalopndooo?hl=en-US
>>> for the working Chrome App).
>>>
>>> The main choices I've seen so far in this thread are:
>>>
>>> * text editor vs traditional notebook
>>>
>>> I prefer the traditional notebook for the reasons Nicholas gave.
>>>
>>> * Storing model in browser vs the same place as the kernel.
>>>
>>> I think that we should aim to have both capacities, and that's what me
>>> and Matthias had been aiming for so far. For backends like Google's
>>> realtime API (which is afaik the only free web based backend for this sort
>>> of thing), the model needs to be in the browser.
>>>
>>> * Using derby.js
>>>
>>> It's great to have operational transforms (OTs) taken care of by someone
>>> else. But I'm concerned that locking into this would exclude other
>>> backends such as Google Drive's realtime API. Maybe we could wrap both in
>>> a another layer though.
>>>
>>> Currently I've been prototyping with React, although my prototype is
>>> much less developed than the others posted here. React is nice because,
>>> based on my experience in coLaboratory, there are lots of stateful UI
>>> components in the notebook, and React allows you to store all your state in
>>> one place. However, it also has stateful components if you need them.
>>> Right now I have a list of cells id's, and map from cell id's to cells,
>>> which as Matthias mentioned, seems like the best way to handle realtime,
>>> but also helps keep cell widgets independent of their position in the
>>> notebook.
>>>
>>> Kester
>>>
>>>
>>>
>>> On Thu, Mar 5, 2015 at 8:42 AM, Wes Turner <wes.turner at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 5, 2015 at 1:29 AM, Jared Forsyth <jared at jaredforsyth.com>
>>>> wrote:
>>>>
>>>>>
>>>>> I've managed to get together a tutorial for ipython
>>>>> <http://app.notablemind.org/tutorial/ipython/> and a general
>>>>> navigation tutorial <http://app.notablemind.org/tutorial/>, and more
>>>>> docs are coming soon.
>>>>>
>>>>> I'd love to get your feedback!
>>>>>
>>>>
>>>> At first glance, this looks outstanding!
>>>>
>>>> * Dig the vim shortcuts
>>>> * Dig the split panes (.glyphicon-resize-vertical and
>>>> .glyphicon-option-vertical might work)
>>>>
>>>> Wondering how/where the 'undo' / 'redo' support is implemented, and
>>>> whether it would be possible to port that back upstream?
>>>>
>>>> Thanks!
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150305/ed081d1b/attachment.html>
More information about the IPython-dev
mailing list