ENB: Leo as a web app?

[Edward K. Ream]

This Engineering Notebook post discusses whether Leo could be a useful web app.

Background

I want to consider whether providing a web-based view of Leo would be a good idea. The goal: create Leo's look on the web while providing Leo's essential features via Leo's bridge.

The JupyterLab system shows that Leo as a web app is feasible.  Whether making Leo a web app is a good idea is an open question.

JupyterLab requires jupyter on the desktop. Similarly, Leo in the browser will use the desktop version of Leo.

As discussed in the previous ENB, web apps must have a substantial js/ts component. There are many front-end frameworks that we could use, including angular, react, vue.js, and more. So this general topic is appropriate for the sabbatical.

leoInteg (Leo for vs-code) is a kind of prototype for Leo as a web app. The biggest technical hurdle facing leoInteg is communicating with Leo's bridge. Recent work with descriptive (json-based) guis shows that a clean interface between Leo and the js/ts words is feasible.

Leo's leoflexx plugin and Joe Orr's leovue web app are useful prototypes. I'll mine them for ideas.

Summary

JupyterLab shows that a web-based interface can use python's full features. It's an open question whether making Leo a web app is worth doing. However, exploring this question is highly appropriate for this sabbatical.

Communication between the browser and Leo's bridge is the central design problem. leoInteg confronts the same problem; leoInteg's solutions will likely apply.

JupyterLab requires jupyter on the desktop. Similarly, Leo in the browser will use the desktop version of Leo.

Edward

[gar]

It depends on how rich leo-in-web become. If the same feature-full as a console version of UI - then no, thank you.

If rich enough to use it as a general-purpose note-taking server tool behind web-server - then why not, great.

The main concern that UI must be enough featureful to make notes and search.

[Edward K. Ream]

Thanks for these comments. I agree that Leo as a web app would have to be a fully functional product. For me the lure is the cool Leovue graphics. But python is my passion. Why not support similar graphics is Leo using python graphics libs? I'll investigate this path soon.

Edward

[Viktor Ransmayr]

Hello Edward,

I'm not sure about the importance of adding another python graphics framework / library for Leo's user base - but - that's my personal view.

What I'm sure about, at least for me, is the value of a general-purpose outliner,  which will allow to provide & keep any kind of notes (daily- or topic-based) accessible via a tab in your browser.

Some limited support is already available via the 'render' pane & for example the 'rst3' command - but - there's no short & simple workflow available and/or described, that I'm aware of.

I just wanted to state this, since I considered that the *main* message in gar's comment.

With kind regards,

Viktor

[tbp1...@gmail.com]

Viktor, could you say more about the workflow you are thinking of?  For myself so far, I am happy to keep Leo open in its own app outside a browser.  And I would prefer to avoid running a server on my system to mediate between Leo and the browser.  However, without a server, it's not really practical to store the Leo outlines on your computer in a way that you can retrieve using other browsers or programs. (yes, you can use LocalStorage, but that can only be accessed by the browser that created it, IIUC.  And yes, you can do it if you are willing, say, to use an in-browser java app, but I don't like that way, either.)

[Edward K. Ream]

On Sun, Jan 31, 2021 at 5:40 AM Viktor Ransmayr <viktor....@gmail.com> wrote:

>> I agree that Leo as a web app would have to be a fully functional product. For me the lure is the cool Leovue graphics. But python is my passion. Why not support similar graphics is Leo using python graphics libs? I'll investigate this path soon.

> I'm not sure about the importance of adding another python graphics framework / library for Leo's user base - but - that's my personal view.

Happily, pyqt suffices to do just about everything that Leovue can do! So my js envy has been replaced.

Googling "pyqt embed youtube video" shows how Leo's rendering pane could show videos.  Similarly for "pyqt x", where x in ("leaflet maps", "mathjax") etc. Why did I never think of this before?

Leo's rendering pane will need third-party libraries for some tasks. Those libs will always be optional, so there is no reason not to forge ahead. I have just created #1810, Support Leovue features in the VR pane.

Edward

[Edward K. Ream]

On Sun, Jan 31, 2021 at 8:15 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Viktor, could you say more about the workflow you are thinking of?  For myself so far, I am happy to keep Leo open in its own app outside a browser.  And I would prefer to avoid running a server on my system to mediate between Leo and the browser.  However, without a server, it's not really practical to store the Leo outlines on your computer in a way that you can retrieve using other browsers or programs.

A timely comment. Yesterday I spent several hours zooming with Félix getting leobridgeserver.py to work with a python test client. I'll write up the results later today.

A client/server architecture is the only way to connect leoInteg (vs-code) to Leo's bridge. And leobridgeserver.py is completely agnostic about the language that clients use.

Otoh, in the last few days it has become clear that I am not looking for anything better than python, or the desktop version of Leo, for that matter.

In short, I am rapidly losing interest in the js world, except to support leoInteg. As #1810 asserts, there is no particular need to make Leovue a full-featured editor.

Suddenly lots of "spare time" has appeared. I'll think of something :-)

Edward

[tbp1...@gmail.com]

On Sunday, January 31, 2021 at 9:26:19 AM UTC-5 Edward K. Ream wrote:

On Sun, Jan 31, 2021 at 5:40 AM Viktor Ransmayr <viktor....@gmail.com> wrote:

>> I agree that Leo as a web app would have to be a fully functional product. For me the lure is the cool Leovue graphics. But python is my passion. Why not support similar graphics is Leo using python graphics libs? I'll investigate this path soon.

[snip]

Happily, pyqt suffices to do just about everything that Leovue can do! So my js envy has been replaced.

Googling "pyqt embed youtube video" shows how Leo's rendering pane could show videos.  Similarly for "pyqt x", where x in ("leaflet maps", "mathjax") etc. Why did I never think of this before?

You can do a lot of graphics display with Leo/VR3  as it is.  The trick is to get the graphics library to output to an image file, then embed that image into an RsT/MD/ADoc page; alternatively, you can often display the output in a non-Leo window or the browser.  I have attached an outline that shows examples using the Holoview, Bokeh, Seaborn, and sci-kit-images libraries.  Of course, you have to install their Python libraries first.

I imagine it might be possible to wrap many of these with a more abstract model.  I haven't looked into that yet.

[Viktor Ransmayr]

tbp1...@gmail.com schrieb am Sonntag, 31. Januar 2021 um 15:15:13 UTC+1:

 

Viktor, could you say more about the workflow you are thinking of?  For myself so far, I am happy to keep Leo open in its own app outside a browser.  And I would prefer to avoid running a server on my system to mediate between Leo and the browser.  However, without a server, it's not really practical to store the Leo outlines on your computer in a way that you can retrieve using other browsers or programs. (yes, you can use LocalStorage, but that can only be accessed by the browser that created it, IIUC.  And yes, you can do it if you are willing, say, to use an in-browser java app, but I don't like that way, either.)

The closest figure I can provide for my envisioned workflow comes from Jupyter project, describing the 'Jupyter Notebook Interface' [1].

Just exchange 'Notebook' with 'Leo Outline' in every box - and - 'Kernel' with 'Leo'.

This is a first, very quick answer from my side. - I'll investigate further on my side as well, where the analogy breaks for Leo ...

With kind regards,

Viktor

---

[1] https://jupyter.readthedocs.io/en/latest/projects/architecture/content-architecture.html#the-jupyter-notebook-interface

[tbp1...@gmail.com]

Viktor, those diagrams describe the Jupyter ecosystem, but not a workflow that uses it.  Your workflow is what I'm interested in.  For example, if you are not doing anything very specific to Jupyter, Leo + VR3 provides a reasonable equivalent.  You can:

- Create and edit a document as a set of nodes.  Leo nodes can be nested and folded in a way that Jupyter nodes cannot;

- View your nodes as fairly well-rendered page or pages;

- Embed and run code - not as many languages as Jupyter, but more could be added.

- View the embedded code, and optionally embed its output.

- Embed graphical output of code into a node.

- Convert a notebook - a set of nodes - into HTML.

It's true that embedding non-text output and graphics is not as convenient as with Jupyter, but it's not very hard, either.  You are also more limited in converting your notebooks into other non-html formats.

The upshot is that it is possible to enjoy many of the core features of Jupyter in Leo already.  You, however, may want to do other things, things that Jupyter does better.  That's why I asked about your workflow.

[Viktor Ransmayr]

tbp1...@gmail.com schrieb am Sonntag, 31. Januar 2021 um 17:22:29 UTC+1:

Viktor, those diagrams describe the Jupyter ecosystem, but not a workflow that uses it.  Your workflow is what I'm interested in.  For example, if you are not doing anything very specific to Jupyter, Leo + VR3 provides a reasonable equivalent.  You can:

- Create and edit a document as a set of nodes.  Leo nodes can be nested and folded in a way that Jupyter nodes cannot;

- View your nodes as fairly well-rendered page or pages;

- Embed and run code - not as many languages as Jupyter, but more could be added.

- View the embedded code, and optionally embed its output.

- Embed graphical output of code into a node.

- Convert a notebook - a set of nodes - into HTML.

OK, I misunderstood your question then - and - I guess I also did not stress enough, that I was referring *only* to the use-cases, that gar called a 'general-purpose note-taking server tool behind web-server'.

Here are my answers in *that* context:

    - Create and edit a document as a set of nodes. - YES.
    - View your nodes as fairly well-rendered page or pages. - YES.
    - Embed and run code. - YES & NO.
    - View the embedded code, and optionally embed its output. - YES & NO.
    - Embed graphical output of code into a node. - YES.
    - Convert a notebook - a set of nodes - into HTML. - NO, I want the HTML
      representation as the default. - As conversion formats I would probably only
      need PDF (in the beginning)

With kind regards,

Viktor

[tbp1...@gmail.com]

On Sunday, January 31, 2021 at 1:46:13 PM UTC-5 viktor....@gmail.com wrote:

tbp1...@gmail.com schrieb am Sonntag, 31. Januar 2021 um 17:22:29 UTC+1:

[snip]

OK, I misunderstood your question then - and - I guess I also did not stress enough, that I was referring *only* to the use-cases, that gar called a 'general-purpose note-taking server tool behind web-server'.

Here are my answers in *that* context:

    - Create and edit a document as a set of nodes. - YES.
    - View your nodes as fairly well-rendered page or pages. - YES.
    - Embed and run code. - YES & NO.
    - View the embedded code, and optionally embed its output. - YES & NO.
    - Embed graphical output of code into a node. - YES.
    - Convert a notebook - a set of nodes - into HTML. - NO, I want the HTML
      representation as the default. - As conversion formats I would probably only
      need PDF (in the beginning)

VR3 when rendering does give you html output.  For getting pdf output, that isn't currently provided for.  There are several ways to get pdf from rst (and, I suppose, MD, though I haven't looked at that  yet).  It shouldn't be hard to add that capability, if someone really wants it.

So from what you say here, probably Leo + VR3 would provide most if not all of what you want from Jupyter.  Is that a fair statement?  And if not, could you elaborate on what would be missing?

[Viktor Ransmayr]

• Both gar & myself were responding to Edward's ENB entry on "Leo as a **web app**?".
• Edward himself was referring to JupyterLab in his entry. - According to my understanding it is the next generation of the web-based client interface to the Jupyter ecosystem.
• I was using the high-level 'Jupyter Notebook Interface' (somewhat wrongly, since I was comparing apples with oranges) as my quick answer to your question about the needed workflow of the 'general-purpose note-taking server tool behind web-server' mentioned by gar.
• What I want to discuss is the access to a Leo outline from one tab in the browser, in order to store my findings as notes in this outline, w/o leaving the browser ...

I hope this explains, why in this context VR3 is not an answer for me.

With kind regards,

Viktor

[tbp1...@gmail.com]

So there is a difference between us - I don't feel a need to do note-taking, etc. in a browser tab.  Fair enough.