Re: The design of Leo+Ipython+Jupyter+Lit-computing

Looks like it works pretty much as expected, if you know the right classes to use. I inserted a QML view into a regular PyQt container, no problem. The view was a QDeclarativeView imported from PyQt4.QtDeclarative. I don't know if they have all the widgets we'd want to use as QDeclaratives

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Sun, 11 Mar 2018 07:05:54 -0700 (PDT) Thomas Passin wrote: > I haven't worked on anything much in-browser since before html5 came > out. So I didn't know anything about "~=", for example. Even then I > tried to only work with the simpler constructs (both javascript and >

Re: The design of Leo+Ipython+Jupyter+Lit-computing

I haven't worked on anything much in-browser since before html5 came out. So I didn't know anything about "~=", for example. Even then I tried to only work with the simpler constructs (both javascript and css), so I probably wouldn't have used that particular construct anyway. On Saturday,

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Sat, 10 Mar 2018 18:46:12 -0800 (PST) Thomas Passin wrote: > Do you happen to know if it's feasible to use QML widgets in Leo? I > don't know either Qt or QML, but much of the PyQt code I see in Leo > looks very painful, a steep learning curve to climb. I remember when

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Do you happen to know if it's feasible to use QML widgets in Leo? I don't know either Qt or QML, but much of the PyQt code I see in Leo looks very painful, a steep learning curve to climb. I remember when I wrote my Matplotlib graphics plotting and calculator program, finding out how to do

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Sat, 10 Mar 2018 17:41:47 -0800 (PST) Thomas Passin wrote: > 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. I have a long term goal of

Re: The design of Leo+Ipython+Jupyter+Lit-computing

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

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tuesday, January 10, 2017 at 12:14:44 PM UTC-5, Offray Vladimir Luna Cárdenas wrote: I would give priority to @cell directive and interaction with (I)python > kernels (maybe via yoton), even if other @-directives for the notebook are > not supported at the beginning. > I agree. >

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Hi, Thanks Edward for your rational and calm answer, even when such attempts to diminish the quality of conversation or new directions arise. Cheers, Offray On 10/01/17 18:08, Edward K. Ream wrote: On Tue, Jan 10, 2017 at 1:23 PM, Mike Hodson >

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tue, Jan 10, 2017 at 1:23 PM, Mike Hodson wrote: I must ask, with all this extending to great big new things, all I've > wanted from Leo for over a year now is the ability for it to save a file > without causing the entire user interface to redraw itself. > ​The redraw

Re: The design of Leo+Ipython+Jupyter+Lit-computing

for this?  https://github.com/leo-editor/leo-editor/issues Cheers -Terry From: Mike Hodson <myst...@gmail.com> To: leo-editor@googlegroups.com Sent: Tuesday, January 10, 2017 12:23 PM Subject: Re: The design of Leo+Ipython+Jupyter+Lit-computing I must ask, with all this ext

Re: The design of Leo+Ipython+Jupyter+Lit-computing

No idea. You could open a new thread on that one with specific details. See you there ;-). Cheers, Offray On 10/01/17 13:23, Mike Hodson wrote: I must ask, with all this extending to great big new things, all I've wanted from Leo for over a year now is the ability for it to save a file

Re: The design of Leo+Ipython+Jupyter+Lit-computing

I must ask, with all this extending to great big new things, all I've wanted from Leo for over a year now is the ability for it to save a file without causing the entire user interface to redraw itself. how hard is it to decouple the UI from the gears behind it, vs adding all this new cruft? --

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Hi, On 10/01/17 12:14, Offray Vladimir Luna Cárdenas wrote: For example I have some @icell (for interactive cell) and Leo presumes that the contents are python and let them to be executed with a shortcut and to import the output into the cell (defining another @language inside the @icell

Re: The design of Leo+Ipython+Jupyter+Lit-computing

Hi, On 10/01/17 02:55, Edward K. Ream wrote: [...] *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

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tuesday, January 10, 2017 at 9:56:48 AM UTC-5, Edward K. Ream wrote: Leo's existing infrastructure is already remarkably useful. > As a further example, Leo's uA's easily suffice to hold all data in .ipynb files, which have .json format. EKR -- You received this message because you are

Re: The design of Leo+Ipython+Jupyter+Lit-computing

On Tuesday, January 10, 2017 at 2:55:34 AM UTC-5, Edward K. Ream wrote: > *Summary* > 1. New Leo directives will designate subtrees as containing IPython > *cells*. > ... > > 2. Leo's existing @language directives will indicate the type of cell. > Leo's existing infrastructure is already

The design of Leo+Ipython+Jupyter+Lit-computing

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