Re: ENB: Leo as a web app?

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? >> &

Re: ENB: Leo as a web app?

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? > - Both gar & myself were responding to Ed

Re: ENB: Leo as a web app?

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, th

Re: ENB: Leo as a web app?

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 provide

Re: ENB: Leo as a web app?

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

Re: ENB: Leo as a web app?

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 > m

Re: ENB: Leo as a web app?

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 > 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

Re: ENB: Leo as a web app?

On Sun, Jan 31, 2021 at 8:15 AM 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

Re: ENB: Leo as a web app?

On Sun, Jan 31, 2021 at 5:40 AM Viktor Ransmayr 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 inves

Re: ENB: Leo as a web app?

gt;> The main concern that UI must be enough featureful to make notes and >>> search. >>> >> >> 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. >>

Re: ENB: Leo as a web app?

t; 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. >> > > Thanks for these comments. I agree that Leo as a web app would

Re: ENB: Leo as a web app?

he main concern that UI must be enough featureful to make notes and > search. > 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

Re: ENB: Leo as a web app?

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 sea

ENB: Leo as a web app?

The JupyterLab <https://jupyterlab.readthedocs.io/en/stable/>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.

Re: Security in Leo as a web app (LeoWapp)

On Mon, Oct 22, 2018 at 7:11 AM Edward K. Ream wrote: > In another thread I wrote: > > "Leo looks like an unverifiable cgi script to the server, which means one > user (or small, *trusted *group of users) must be *fully* responsible for > the damage Leo could cause. It might be possible to host a

Re: Leo as a web app.

On Tue, Oct 16, 2018 at 5:01 PM Terry Brown wrote: > Here's a Dockerfile that let's Leo (The Python3 / PyQt4 version) run in > a web browser. This is cheating, and I think I demoed this years ago > without Docker, but it might be useful for someone. > Thanks for this. I've just bookmarked this

Re: Security in Leo as a web app (LeoWapp)

Someone should look at Heroku. It seems that they do containers that already support python that is designed to face the web. They also have a robust and complete local CLI client. It is very convenient for working on apps with a web face. Chris On Mon, Oct 22, 2018 at 5:55 AM vitalije wrote:

Re: Security in Leo as a web app (LeoWapp)

I am not 100% sure but I believe that it is possible to start docker instance on some remote host (one instance per user or per script invocation) and let python execute script inside that docker instance. A malicious script can try to damage server but the damage will remain inside its own doc

Security in Leo as a web app (LeoWapp)

In another thread I wrote: "Leo looks like an unverifiable cgi script to the server, which means one user (or small, *trusted *group of users) must be *fully* responsible for the damage Leo could cause. It might be possible to host a Leo server in a per-user (or per-small group) virtual machine

Re: Leo as a web app.

Cool, thanks Terry Matt -- 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@g

Leo as a web app.

Here's a Dockerfile that let's Leo (The Python3 / PyQt4 version) run in a web browser. This is cheating, and I think I demoed this years ago without Docker, but it might be useful for someone. Would be interested to hear if anyone tries it / runs in to issues. Easier to understand if you're famil

Re: An xslt prototype for a read-only version of Leo as a web app

On Wednesday, February 18, 2015 at 9:54:15 AM UTC-6, Edward K. Ream wrote: I have been wondering whether it would be possible to use xslt to render > .leo files from web pages. > A brief update. My brother speed is working on server-side solutions to the various problems I mentioned. We want

Re: An xslt prototype for a read-only version of Leo as a web app

On Wed, Feb 18, 2015 at 3:23 PM, Jacob Peck wrote: > > On 2/18/2015 10:54 AM, Edward K. Ream wrote: > > 1. Visiting http://leoeditor.com/xslt-test.leo does not work. > > The browser renders xslt-test.leo xml, not html. That is, the browser > does not perform the xslt transformations. > > Your w

Re: An xslt prototype for a read-only version of Leo as a web app

On 2/18/2015 10:54 AM, Edward K. Ream wrote: 1. Visiting http://leoeditor.com/xslt-test.leo does not work. The browser renders xslt-test.leo xml, not html. That is, the browser does not perform the xslt transformations. Your web server is configured to send .leo files as MIME type 'text/pla

Re: An xslt prototype for a read-only version of Leo as a web app

On Wed, Feb 18, 2015 at 7:54 AM, Edward K. Ream wrote: > 2. Open xslt-test.leo in your browser. You should see something like this: Yes I see an html rendered page. This is great! For the remote-origin security issue: as long as the .leo file and .xlst file reside on the same domain, shouldn

An xslt prototype for a read-only version of Leo as a web app

on of Leo as a web app! = About leo_to_html.xsl Ville created leo_to_html.xsl, but I didn't understand its significance until early this morning. This xslt file tells a web browser (or other xslt processor) how to render a .leo file as html. I made several changes this

Re: Leo *for* web apps vs. Leo *as* a web app

On Thu, Jan 29, 2015 at 9:33 AM, Ville M. Vainio wrote: > Leo already works with ipython, but I'm aware we are talking about ipython > notebook here ;). > > I think I did an experiment on this back in the day - it would involve > launching "ipython kernel" (that hosts all the data, and that is us

Re: Leo *for* web apps vs. Leo *as* a web app

Leo already works with ipython, but I'm aware we are talking about ipython notebook here ;). I think I did an experiment on this back in the day - it would involve launching "ipython kernel" (that hosts all the data, and that is used as a backend for the web frontend) in the Leo process. This woul

Re: Leo *for* web apps vs. Leo *as* a web app

> ​The biggest win-win that I can see would be to "insinuate" Leo somehow > into IPython. > Count me for one that would love this! Matt -- 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

Re: Leo *for* web apps vs. Leo *as* a web app

On Wed, Jan 14, 2015 at 5:35 AM, Jacob Peck wrote: > This means that *one single codebase* will run on Windows, Linux, Mac OS > X, Android, iOS, Blackberry OS, Windows Phone, Tizen, Mozilla/Firefox OS, > etc, with no complicated user installation. dunno if it's relevant here, but Docker is on

Re: Leo *for* web apps vs. Leo *as* a web app

​​ ​On Wed, Jan 14, 2015 at 1:33 PM, Brad wrote: > I understand. My thinking was that if you decide to move ahead, the > IPython (and more generally Jupyter) developers have gone through the > careful process (and pain) of designing an integrated, extensible system > (tornado, zmq, json, javascri

Re: Leo *for* web apps vs. Leo *as* a web app

I understand. My thinking was that if you decide to move ahead, the IPython (and more generally Jupyter) developers have gone through the careful process (and pain) of designing an integrated, extensible system (tornado, zmq, json, javascript) that may be of use in a more general context. This

Re: Leo *for* web apps vs. Leo *as* a web app

In the browser would also benefit the outreach issue: http://leo-editor.com/demo ... On Wed, Jan 14, 2015 at 9:58 AM, Jacob Peck wrote: > > On 1/14/2015 10:55 AM, Edward K. Ream wrote: >> >> Writing to a local device involves having a server running on that device. > > Nope -- HTML5 brought supp

Re: Leo *for* web apps vs. Leo *as* a web app

On 1/14/2015 11:28 AM, Edward K. Ream wrote: Is there any impediment to using Leo with files that are in the local DropBox folder? ​Not that I know of. I just created @file \Dropbox\test.py​ ​and saved it. Changed test.py in the Dropbox folder. The changes appear when I reloaded

Re: Leo *for* web apps vs. Leo *as* a web app

> Is there any impediment to using Leo with files that are in the local > DropBox folder? ​Not that I know of. I just created @file \Dropbox\test.py​ ​and saved it. Changed test.py in the Dropbox folder. The changes appear when I reloaded the .leo file containing the @file node. Edward --

Re: Leo *for* web apps vs. Leo *as* a web app

On Wed, 14 Jan 2015 08:35:00 -0500 Jacob Peck wrote: >- elsewhere in 'the cloud' (DropBox? SpiderOak?) Is there any impediment to using Leo with files that are in the local DropBox folder? Hmm, I have DropBox synced. on my phone, but the Android outliner DGT GTD links directly to my DropBo

Re: Leo *for* web apps vs. Leo *as* a web app

On Wed, Jan 14, 2015 at 9:58 AM, Jacob Peck wrote: > > On 1/14/2015 10:55 AM, Edward K. Ream wrote: > >> Writing to a local device involves having a server running on that >> device. >> > Nope -- HTML5 brought support for localstorage and the FileSystem API. > Web apps can write persistent files

Re: Leo *for* web apps vs. Leo *as* a web app

On 1/14/2015 10:55 AM, Edward K. Ream wrote: Writing to a local device involves having a server running on that device. Nope -- HTML5 brought support for localstorage and the FileSystem API. Web apps can write persistent files to client devices. http://www.noupe.com/design/html5-filesystem-ap

Re: Leo *for* web apps vs. Leo *as* a web app

On Wed, Jan 14, 2015 at 9:43 AM, Jacob Peck wrote: > > On 1/14/2015 10:38 AM, Edward K. Ream wrote: > > The cross-platform support is the key here. Being able to run it on *any* > device with a modern web browser is crazy useful. Leo on my tablet, Leo on > my phone, Leo on my thermostat! A b

Re: Leo *for* web apps vs. Leo *as* a web app

On Wed, Jan 14, 2015 at 7:43 AM, Brad wrote: > Can any of the lessons learned and infrastructure from the IPython > notebook and project Jupyter (https://jupyter.org/) be of use? > ​Excellent question.​ ​I hadn't known about jupyter ​until just now, but it's derived from IPython so let's preten

Re: Leo *for* web apps vs. Leo *as* a web app

On 1/14/2015 10:38 AM, Edward K. Ream wrote: The question is, would wLeo be an improvement over plain Leo. At present, I do not see how. For example, plain Leo will have *much* better drawing and file-related performance than wLeo​ ​ . And if wLeo is merely going to deal with local files the

Re: Leo *for* web apps vs. Leo *as* a web app

On Wed, Jan 14, 2015 at 7:35 AM, Jacob Peck wrote: > wLeo could access .leo files in a variety of spaces: > > - Local files > - github repos > - elsewhere in 'the cloud' (DropBox? SpiderOak?) > - stored on a private server > ​True. The question is, would wLeo be an improvement over p

Re: Leo *for* web apps vs. Leo *as* a web app

Can any of the lessons learned and infrastructure from the IPython notebook and project Jupyter (https://jupyter.org/) be of use? -Brad On Wednesday, January 14, 2015 at 5:31:38 AM UTC-7, Edward K. Ream wrote: > > I suspect that I shall be studying web technologies this year. They are > way to

Re: Leo *for* web apps vs. Leo *as* a web app

On 1/14/2015 7:31 AM, Edward K. Ream wrote: Web apps are connected to severs that (surprise) actually serve up content (from data bases or news feeds or something else). But what would wLeo serve up? Well, a .leo file, presumably on a *local* machine. That being so, we might as well use Leo

Leo *for* web apps vs. Leo *as* a web app

I suspect that I shall be studying web technologies this year. They are way too important to ignore any longer. Besides, they are interesting technologies. Let me state a preliminary conclusion, which may not last more than a few hours: Leo has no real future *as* a web app, call it **wL

Re: Leo as a web-app, part 9000

> So it would be easy to setup a recipe for Leo, but arc.io would really > have to take off for it to be worthwhile. Installing arc causes VirtualBox > to be installed and that requires admin rights and that seems like a big > hurdle to me. Maybe not. If installing arc.io is easier than instal

Re: Leo as a web-app, part 9000

On Fri, Oct 4, 2013 at 2:55 PM, Jacob Peck wrote: > Leo might be able to work in such an environment... in which case, there > could be a "launch Leo" button on leoeditor.com to run the whole shebang > right in the browser. > Looking at the example manifest on the home page I could tell right aw

Re: Leo as a web-app, part 9000

On 10/4/2013 3:14 PM, Fidel N wrote: I wonder how u find tose. Hacker News, mostly. http://news.ycombinator.com. -->Jake -- 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

RE: Leo as a web-app, part 9000

Regarding arc.io, there seems to be a cognitive disconnect between what it says on the box and the installation instructions: http://arc.io/install ...If it depends on a local installation of VirtualBox in order to run a native apps in the browser, then what exactly is arc.io bringing to the tab

Re: Leo as a web-app, part 9000

WOW very interesting. I wonder how u find tose. On Friday, October 4, 2013 8:55:44 PM UTC+2, Jacob Peck wrote: > > Looks like a new tech is coming up called Arc. http://arc.io/ > > It basically gives users a complete Linux VM in their browser, with full > capabilities (meaning an actual python p

Leo as a web-app, part 9000

Looks like a new tech is coming up called Arc. http://arc.io/ It basically gives users a complete Linux VM in their browser, with full capabilities (meaning an actual python process, not just a subset/poor javascript translation). Leo might be able to work in such an environment... in which c

Re: Why Leo as a web app is unlikely

If Kivy is the solution (with what I would actually agree very much), please say what you want to get before you start working on it, because I think I could give some useful info and scripts that already work from Leo. I have been working

Re: Why Leo as a web app is unlikely

On Thursday, September 19, 2013 7:55:22 PM UTC-5, Differance wrote: > > 2. Creating a Leo outline widget is extremely complex. Even starting > with a > > working javascript outliner, one has to deal with events (commands) > coming > > from Leo scripts rather than from the user. > > I wonde

Re: Why Leo as a web app is unlikely

On Thu, Sep 19, 2013 at 9:27 PM, Terry Brown wrote: > > > There are two reasons why Leo is unlikely ever to be a web app. > > By web app. you mean in-browser app., I'm assuming. > Correct. > > > 1. There are somewhere around a million lines of Python code in Leo's > core > > and plugins. Thu

Re: Why Leo as a web app is unlikely

On Thu, 19 Sep 2013 15:19:06 -0700 (PDT) "Edward K. Ream" wrote: > There are two reasons why Leo is unlikely ever to be a web app. By web app. you mean in-browser app., I'm assuming. > 1. There are somewhere around a million lines of Python code in Leo's core > and plugins. Thus, a *solid* py

Re: Why Leo as a web app is unlikely

On Thu, Sep 19, 2013 at 6:19 PM, Edward K. Ream wrote: > There are two reasons why Leo is unlikely ever to be a web app. > > 1. There are somewhere around a million lines of Python code in Leo's core > and plugins. Thus, a *solid* python in javascript system is required. This > isn't likely to h

Why Leo as a web app is unlikely

There are two reasons why Leo is unlikely ever to be a web app. 1. There are somewhere around a million lines of Python code in Leo's core and plugins. Thus, a *solid* python in javascript system is required. This isn't likely to happen. 2. Creating a Leo outline widget is extremely complex.