Web leo

[Terry Brown]

For the next 2.25 weeks I'm going to be traveling, Reykavik and St.
Petersburg (Russia, not Florida :-). So there may not be much more to
report for a while, but I've started what looks like a promising
attempt at a web interface to Leo. Very much based on a path of least
resistance for my skill set.

So far you can drag nodes around the tree, cut and paste and insert
them, and edit the headline text. And tell the server to save the
outline. The architecture is:

Python's BaseHTTPServer running the 'server'.
New code ('leoweb.py') communicating with the browser.
jQuery and jQuery-UI handling the interface (authored in coffeescript).
And the critical link - leoBridge as the backend for leoweb.py.

So in an odd way this is a database driven Leo, using Leo as the
backend database :-) I'm trying to minimize the dependencies,
currently they're essentially zero, seeing jQuery and jQuery-UI are
publicly hosted.

Still some work on the core to do, i.e. handling expansion /
contraction properly. Then body text editing, which should be
reasonably straight forward. Then... and this is where this can become
so much more than just another on line outliner, minibuffer commands.
Which of course is a huge security issue, but never mind that for now.

Because of the path of least resistance requirement I'm not trying to
implement a Leo UI, i.e. another version of Leo's UI code of which
there is currently the nullGui and Qt versions, and used to be the Tk
version. This might evolve in that direction, or not, I'm not sure.
The event loop is in the user's browser in javascript and not on
the server in python. But it would be a shame not to be able to do
some of the things that require knowledge of body editor cursor position
and selected text, for example, so we'll see what happens.

So currently it's essentially a new, coffee/javascript based editor of
Leo outlines with the power of leoBridge to call on.

Cheers -Terry

[Jacob Peck]

Sounds awesome. I had been kicking around the idea of a javascript leo
outline *viewer* (not editor) that would pull .leo files from
gist.github.com, and display them, as a quick way of sharing outlines
with others, as, to (mis-)quote Edward, "Leo doesn't do email very
well". This sounds like just the thing... assuming you open up the
codebase, it probably wouldn't be hard to hack in a "grab from gist"
method to pull in .leo outlines, giving us a sort of pastebin for .leo
outlines.

-->Jake

[Fidel Pérez]

+1, sounds awesome!!

Also, have a lot of fun in your travels through Russia, post some photos will you hehe.

I hope you come back with renewed energies and ideas after that trip, talk soon!

[Matt Wilkie]

> So currently it's essentially a new, coffee/javascript based editor of
> Leo outlines with the power of leoBridge to call on.

this sounds very cool Terry!

enjoy your travels. I've always been intrigued by Iceland and hope to
get there myself one data. :)

-matt

[David McNab]

In the "Rules of the Internet" (www.rulesoftheinternet.com), Rule 34 says "There is porn of it, no exceptions". This means that if anything exists, there is a porn version of it somewhere, and if there isn't, there soon will be.

The rules need to be updated to include Rule 34j, which states "There is a client-side javascript version of it". In other words, for all software, there is a corresponding javascript program that is rapidly evolving to achieve the same thing.

Terry, what you're doing is brilliant and long overdue. The whole computing world is headed into the cloud, and if Leo is to stay relevant, it needs to go there as well.

What I would ask is does your JS Leo allow concurrency? What a Cloud Leo desperately needs is the ability to have n people editing it concurrently and seeing where each other are at, just like with Google Docs.

I am hanging out to see how this evolves.

Cheers

David

--
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+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.

[Terry Brown]

On Thu, 20 Jun 2013 06:59:18 +1200
David McNab <davidm...@gmail.com> wrote:

> What I would ask is does your JS Leo allow concurrency? What a Cloud Leo
> desperately needs is the ability to have n people editing it concurrently
> and seeing where each other are at, just like with Google Docs.

Currently the server isn't "pushing" stuff to the browser, but I expect
it will be at some point. So simplistically you could have
concurrency, but I've no idea how it would work out conflict wise.
What happens when you're editing a node somewhere on a subtree and
someone deletes the whole subtree? Or if people move subtrees around
in inconsistent ways? I guess some level of etiquette might help, but
to make it robust, I'm not sure.

So my feeling was there are some hard parts out there, but starting
simple will create a place to experiment. It's already almost at a
point where it could be used for shared list making, with surprisingly
little code.

Cheers -Terry

[David McNab]

Terry,

Those are good questions.

Some ideas could be drawn from how Google Documents and Spreadsheets do their concurrency.

As for Leo, you raise some serious issues, but with some careful thought these could be resolved with a combination of subtree locking and a chat window.

For example, if I'm editing a node, nobody will be able to delete or move that node or any of its ancestors until or unless I commit my changes.

Cheers

David

[Kent Tenney]

The vim approach
http://www.fredkschott.com/post/50510962864/introducing-covim-collaborative-editing-for-vim

looks hard to grok without using it, but there are tabs for each participant
(the blue one looks a lot like terry_brown)

Terry's work could offer a shared view of document structure, covim might
could offer collaborative editing of node bodies, possibly a manageable degree
of collaboration.

[Terry Brown]

On Wed, 19 Jun 2013 15:38:16 -0500
Kent Tenney <kte...@gmail.com> wrote:

> The vim approach
> http://www.fredkschott.com/post/50510962864/introducing-covim-collaborative-editing-for-vim
>
> looks hard to grok without using it, but there are tabs for each participant
> (the blue one looks a lot like terry_brown)

I'm not sure if those are tabs or just a color coded key for the owners
of the different cursors in the document.

The way Google Docs. handles multiple simultaneous editors is very
slick, I guess they may have some locking mechanisms for preventing
deletion of a para. someone else is editing.

Not sure if I'll be able to get to the point of sharing before I leave,
but for those who've worked with web apps., I'm leaning towards
'long polling' rather than websockets, because it's easier. When I've
done this sort of thing before I've found even simple 0.5 second polling
works ok.

Cheers -Terry

[Matt Wilkie]

Dunno if this will have any bearing at all on your work Terry, but the
synchronicity of this coming to my attention unbidden is too
interesting to ignore: http://www.firepad.io/

"""
How is Firepad different than other collaborative text editors?

Most collaborative text editors require special code to run on a
server, making them impractical to use if you're not already using the
right server stack. Firepad has no server dependencies and instead
relies on Firebase for real-time data synchronization. This means that
it's easy to add Firepad to any application, even static websites. All
you need to do is drop in the JavaScript files and go.
"""

The magic is in the backend, Firebase, whose approach to mirroring and
synchronizing distributed database is "be like dropbox", e.g. it's a
cloud service. The pricing model is curious, a free tier (of course,
gotta get 'em hooked), and then a jump to $24/mth. Seems to me a
rather big jump.

Anyway, just thought I'd share so the ideas behind the product more
than the actual product itself are part of the mix.

cheers,

-matt

[Fidel Pérez]

Wow +1 Firepad looks like a great beggining

[Terry Brown]

On Thu, 20 Jun 2013 21:22:47 -0700
Matt Wilkie <map...@gmail.com> wrote:

> Dunno if this will have any bearing at all on your work Terry, but the
> synchronicity of this coming to my attention unbidden is too
> interesting to ignore: http://www.firepad.io/

That came up on the G+ Leo Editor community a while back :-)

https://plus.google.com/u/0/communities/104562683923003520885

Cheers -Terry

[Zoom.Quiet]

why not make subl-leo package?
- under MAC, Qt-Leo is so some ogg edit action...

> --
> 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+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!
俺: http://about.me/zoom.quiet
许: http://creativecommons.org/licenses/by-sa/2.5/cn/

[Matt Wilkie]

> That came up on the G+ Leo Editor community a while back :-)

huh, maybe that's why that particular flutterby captured my attention long enough to read it. :)

-matt

[Edward K. Ream]

On Wed, Jun 19, 2013 at 1:59 PM, David McNab <davidm...@gmail.com> wrote:

 

The rules need to be updated to include Rule 34j, which states "There is a client-side javascript version of it". In other words, for all software, there is a corresponding javascript program that is rapidly evolving to achieve the same thing.

Haha!

Terry, what you're doing is brilliant and long overdue.

I agree.  Thanks for your work.
 

The whole computing world is headed into the cloud, and if Leo is to stay relevant, it needs to go there as well.

I have mixed thoughts about this.  If we could magically make Leo work in the cloud, then that would be great.  However, I don't want to maintain two code bases, one in js and one in python.  And nobody else will want to maintain two code bases either.

Also, I think of Leo as a python-based editor.  A js (or coffee-script) based editor would be something different, imo.

There are several python-in-javascript projects (just google "python in javascript"), but iirc according to Guido all are in trouble.  I suspect that python in javascript may be one of those ideas that sound good but are actually doomed.  There is a term for such things, but I forget what it is.

These are my present thoughts, but I don't want to discourage Terry's work in any way!  Let's see what happens...

Edward

[Edward K. Ream]

On Saturday, June 29, 2013 7:33:35 AM UTC-5, Edward K. Ream wrote:

On Wed, Jun 19, 2013 at 1:59 PM, David McNab <davidm...@gmail.com> wrote:

 

The whole computing world is headed into the cloud, and if Leo is to stay relevant, it needs to go there as well.

I have mixed thoughts about this.  If we could magically make Leo work in the cloud, then that would be great.  However, I don't want to maintain two code bases, one in js and one in python.  And nobody else will want to maintain two code bases either.

When I wrote this reply I missed the fact that the approach is based on the Leo bridge, which contains all of Leo's core.  So Terry's way would *not* seem to require Python in js, at least not write away ;-)

Edward

[stl]

Hi Terry,

I am relatively new to Leo.  And your post is most relevant to what I am trying to do.

I am trying to use leoBridge within a python cgi script.  I am using apache2.  The leoBridge code was excerpted from the Leo5.0 documentation.

For some reason, leoBridge.controller remains closed when I invoke the script from the browser.  In other words, controller.isOpen() always returns False.  (Consequently, I get attributeError due to NoneType when the script tries to access functions in controller.)

I run the same script via cmd-prompt and everything seems to work (e.g., traversing various nodes).

Am I missing something obvious?  

Your approach with leoweb.py seems to suggest that leoBridge cannot be embedded within a cgi script.

Thanks!

stl

[Terry Brown]

Hi stl,

I don't have an appropriate machine for checking just now, but I think I wrote a note somewhere about running leobridge and some tricks to do with the environment. I would try having your script display/print os.environ and sys.path and check for differences between the command line and browser situations. That might not be exactly the right place to look, I'll see if I can find the note. Check the current directory in the two situations too.
Cheers -Terry

[stl]

Thanks Terry!

I used the os.environ() and sys.path() to ensure that the command-line and browser situations have exactly the same paths.  In both situations, I am invoking the same script in the same cgi-bin directory.

However, controller.isOpen() still returns False.  

Let me know if you found that note.  In the meantime, I'll continue to puzzle over this problem.

-Scott