f 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
ly 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 Edward's ENB entry on "
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,
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
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
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
>
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
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
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
e 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 pytho
>> 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 wo
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
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
<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.
As dis
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
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
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
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
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
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
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
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
On Wed, Feb 18, 2015 at 3:23 PM, Jacob Peck gatesph...@gmail.com 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
On Wed, Feb 18, 2015 at 7:54 AM, Edward K. Ream edream...@gmail.com 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
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
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 morning
On Thu, Jan 29, 2015 at 9:33 AM, Ville M. Vainio vivai...@gmail.com 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,
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 would
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 it,
On Wed, Jan 14, 2015 at 5:35 AM, Jacob Peck gatesph...@gmail.com 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,
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
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 too
On Wed, Jan 14, 2015 at 7:35 AM, Jacob Peck gatesph...@gmail.com 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
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.
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
path-to-dropbox\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.
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 gatesph...@gmail.com 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
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
On Wed, Jan 14, 2015 at 7:43 AM, Brad brad.reisf...@gmail.com 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
On Wed, Jan 14, 2015 at 9:43 AM, Jacob Peck gatesph...@gmail.com 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
On Wed, 14 Jan 2015 08:35:00 -0500
Jacob Peck gatesph...@gmail.com 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
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
path-to-dropbox\Dropbox\test.py
and saved it. Changed test.py in the Dropbox folder. The changes
appear
On Wed, Jan 14, 2015 at 9:58 AM, Jacob Peck gatesph...@gmail.com 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
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
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
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
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
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
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
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
On Fri, Oct 4, 2013 at 2:55 PM, Jacob Peck gatesph...@gmail.com 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
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
On Thu, Sep 19, 2013 at 9:27 PM, Terry Brown terry_n_br...@yahoo.comwrote:
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
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 wonder how
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.
On Thu, Sep 19, 2013 at 6:19 PM, Edward K. Ream edream...@gmail.com 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
On Thu, 19 Sep 2013 15:19:06 -0700 (PDT)
Edward K. Ream edream...@gmail.com 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.
56 matches
Mail list logo
