Using A Leo Outline On Another Computer (Part 2)

42 views
Skip to first unread message

tbp1...@gmail.com

unread,
Mar 13, 2022, 6:21:36 PM3/13/22
to leo-editor
Continuing the previous discussion (Using a Leo Outline On Another Computer?), we don't even have to change leoserver.  Instead, we can import it and monkey patch it.  Basically, import leo.core.leoserver, and then add the following:

SetEncoder = leoserver.SetEncoder
InternalServerError = leoserver.InternalServerError
ServerError = leoserver.ServerError
TerminateServer = leoserver.TerminateServer
ServerExternalFilesController = leoserver.ServerExternalFilesController
LeoServer = leoserver.LeoServer
main = leoserver.main
leoserver.wsHost = "10.0.0.58"  # If we want to change the default 

def send_outline(self, param):
    filename = param.get('path', '')
    result = ''
    if filename and os.path.exists(filename):
        with open(filename, encoding = 'utf-8') as f:
            result = f.read()

    data = {"outline": result}
    return self._make_response(data)

LeoServer.send_outline = send_outline


Of course, we could add other new methods the same way.  This approach works with my little test client.  

tbp1...@gmail.com

unread,
Mar 13, 2022, 11:51:06 PM3/13/22
to leo-editor
This works - the little client script together with the monkey-patched leoserver was able to transfer an outline from my desktop to the laptop.  However, the outline wasn't actually getting inserted into the new outline.  I had to actually go through that clipboard to make that happen.  I don't understand that, but it seems like a minor matter.

So we have the beginnings of a little system here.  More error handling, the complementary save function, and a way to set and track the filename of the file so it can be saved from the remote to the right file on the host: then we'll be in business.

What I like about this approach is its basic simplicity.  Minor extensions to leoserver, which won't necessarily even require changes to leoserver.py itself, and a user-initiated script or two on the remote computer, nothing too complex, thanks to Felix's work on leoserver.  We do need to have the user start the server on the host machine, but we can't avoid that unless we can get Leo to start a server on startup.  I don't imagine we really want that, do we?  But the user could write a batch file that starts both Leo and the server, with --persist of course.

tbp1...@gmail.com

unread,
Mar 13, 2022, 11:59:38 PM3/13/22
to leo-editor
@Edward suggested looking at Tom Brown's leocloud plugin, and I have done that.  It looks like classic Tom Brown work - a somewhat abstract but relatively simple system, with just enough concrete instantiations to help with getting experience and guiding future development.

I don't see it as having direct relevance to this project, though it might be useful as an adjunct.  It can check to see if a file has changed on a  remote system, and restore it if desired.  The file system instantiation wouldn't work (as is) on the remote file system, and trying to go through git would be cumbersome for what I'm trying to do.  And you would still have to transfer the file contents from machine to machine anyway.

Félix

unread,
Mar 14, 2022, 1:55:04 AM3/14/22
to leo-editor
Great to hear your first tests and experiments are moving along well. Like Edward said, I think it's a great idea and am looking forward to help you make it happen in the coming days :)

fun fact: While writing the server, i've always tried to make it client-agnostic and flexible, to encourage people to write clients for it: so i'm super happy about your idea about adding this mode of using Leo itself: as a client for remote usage! 

I've still to finish the update i'm currently making for nav & tag panes in leointeg, (big update coming soon) but i'm almost done, probably a day or two. 

...then i'll try to make the the needed additions to leoserver (to accommodate your project) as I move forward this week. And play with it to try it out and make it work nicely with whatever helps make it work. I'm still pretty sure the send-whole-outline / receive-whole-outline kinda commands are pretty much what's missing on the server to make the whose thing work. Of course a better nomenclature and parameter names are to be chosen - (just throwing ideas out )

Eager to read your thoughts in this forum as you continue to try out things for those features in the meantime :)

Félix




Edward K. Ream

unread,
Mar 14, 2022, 8:05:33 AM3/14/22
to leo-editor
On Sun, Mar 13, 2022 at 10:59 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:
@Edward suggested looking at Tom Brown's leocloud plugin, and I have done that.  It looks like classic Tom Brown work - a somewhat abstract but relatively simple system, with just enough concrete instantiations to help with getting experience and guiding future development.

I don't see it as having direct relevance to this project, though it might be useful as an adjunct. 

Thanks for your investigation. I agree with your conclusion.

Edward

Edward K. Ream

unread,
Mar 14, 2022, 8:09:20 AM3/14/22
to leo-editor
On Sun, Mar 13, 2022 at 5:21 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:
Continuing the previous discussion (Using a Leo Outline On Another Computer?), we don't even have to change leoserver.  Instead, we can import it and monkey patch it. 

Yes, I'm sure that would work. It's a good plan during development.

Imo, it would be best to put the new code into the server eventually. That way the new code becomes easily available to all.

Edward

Félix

unread,
Mar 15, 2022, 12:03:50 AM3/15/22
to leo-editor
> Imo, it would be best to put the new code into the server eventually. That way the new code becomes easily available to all.
 Yes indeed, good point. I'd intended also add anything else that Thomas might come up with that may be useful in any way, to have in the server. (on top of what i've suggested). 

Félix
Reply all
Reply to author
Forward
0 new messages