[proposal] Work with editor in browser

[htzh]

I wonder if you have considered working with an editor in browser instead of VSCode. The Monaco editor underlying VSCode is available independently. I imagine there is a lot more freedom working directly with the editor. And losing the dependence on VSCode and Electron is attractive too.

[boltex]

Hmmm, but then, using Leo integrated in a web-browser based interface such as monaco, or like leovue with editing features, outside of an IDE like vscode, would be equivalent to just replacing the gui engine that Leo uses, (like when it went from qt to tclTk, etc...)

Your proposal would make more sense in my other project: https://github.com/boltex/leojs. Thanks for your great suggestion nonetheless!

I'll look into it right after I finish the last feature of LeoInteg preventing its first official 1.0 launch. (redoing the body pane filesystem provider)

As a first thought : I'm not sure at which point vscode and electron are helping more than impeding, by being in the way on top of just monaco: From one aspect of the project to the other, it might not be as drastic as you might imagine. (although it might be for a small subset of aspects of the project)

Please feel free to add to your proposal and point out things in relation to that, or elaborate some more. Many features of LeoInteg came indirectly from brainstorming with Leo users by commenting back and forth! :)

[htzh]

Yes the main benefit is to provide a browser GUI to Leo. As you mentioned somewhere else Qt is not really the best UI choice. For example there is no native M1 Mac support yet for Qt, which is what had motivated me to look into the alternative UI idea. LeoVUE does not embed an editor as far as I can tell.

There are users who don't need IDEs like VSCode but everyone has a browser already.

What is the main difference between this project and your leojs project?

[htzh]

Also in the long term freedom of the browser UI might allow more creative modes of interaction. Certainly integration with leovue like feature would be welcome.

[htzh]

Maybe a more compelling example would be to run the backend on a server and now you can view and edit your outlines on a phone or a tablet.

[htzh]

Does leojs reimplement Leo functions in Typescript? In a browser we have rather limited access to the local file system. A server is likely needed to make things run smoothly, in which case we might as well reuse Leo Python code rather than reimplementing it? I can see its attractiveness for VSCode extension but I think the python server in this project is more appropriate for the browser UI.

[boltex]

I see what you mean now. You propose something similar to #117 but with the added benefit of running anywhere in any browser, instead of just connecting to a leo server with the existing leoInteg vscode extension.

(I use the term 'benefit' loosely here because doing so would have limited functionality compared to having leo integrated in the full fleddge IDE that is vscode.)

Frankly, it's a very good idea , and I'll start another project to endeavor making it a reality. (any suggestions for a project name?)

Thanks again for this great idea! Please feel free to add more comments to this thread!

Félix

[boltex]

Yes leojs implements the leo functionality in typescript. (javascript). So indeed you are right, a server should run in python and offer remote capabilities.

[htzh]

I think Dandelion, which rhymes with Dandy+Lion could be an interesting project name. It harkens back to a root in Leo but also implies difference and (hopefully) improvement.

[htzh]

One of the early decisions to make architecture wise is whether editor motions should be managed on the client side or server side. If it is to be on server side and fully utilize Leo's editor feature the front end could just map a Leo panel to a textarea? Or the client side could embed full featured editors (for which there are many choices in js) and the backend server side is just used to manage outliner functions (tangling and untangling) and file system.

I think I like the idea of keeping the backend simple and embed full editors on the client side. This way the backend would be neutral and the front end could be browser, IDE, vim or emacs. I believe this is your approach now? So maybe it is not a real decision at all.

[htzh]

Suppose the backend just manages the DAG nodes and file related actions, very little of the Leo code base is actually needed. And you have ported these functions to ts in your leojs project. So there is a question of whether the backend should be python or nodejs.

From a performance point of view I think nodejs is a better choice. It also has a better package manager. But python is likely more widely installed so dependence on nodejs could scare off some people (though I don't know how many potential users are actually out there :)

I have a Python program in Leo outline that I use to track certain transactions for about 15 years now. It has grown to over 40K lines. For my Qt interface on older hardware I ran into obvious GC pauses that freeze the UI for many seconds when I print multiple lines to the log pane. I don't know if this is a problem with Python or just PyQt and it may have been fixed already. The UI also takes many seconds at start up. But all other interactions are still pretty snappy.

Right now it is convenient to write scripts to run my programs in Leo. I think Leo runs them in the same Python runtime that runs itself. If the backend is nodejs then it would take some work to manage an external Python executable.

Since you have a working python backend already it seems to make the most sense to start here and see if there is a need to move to nodejs later.

[htzh]

For frontend UI it could be just like this project though I don't know how easy it is to extract the framework from vscode. There are likely standalone project tree frameworks available but I have not looked for them. There is also the possibility for very different style of UIs. For example Graphql Editor provides a framework for node based systems. One could use the node system for navigation and outline management. I am pretty neutral as long as the UI is easy to use. Whatever is the easiest to implement should probably be the first choice.

I think it makes the most sense to get a functional system up quickly using as much existing code as possible. Then iterative improvements could ensue after we gain some experience using it.

[edreamleo]

@boltex @htzh

Are you aware that Leo already has a browser gui? The leoflexx.py plugin uses Almar Klein's brilliant flexx package.

That said, I'm not particularly happy with leoflexx.py. It's barely more than a proof of concept. In particular, key handling is, at best, second rate.

I am assuming that the discussion here does not affect Leo (or me) directly. Let me know if that's not true, or if I can be of any help.

[boltex]

@htzh Those are great ideas and I'll take them in consideration when switching to using the new leo server instead of the usual original leoBridgeserver, alongside considering remote file opening (from server, or remote user's machine), to address issue #117 and other similar.

Please don't hesitate to add more ideas and details in this thread, Many Thanks!

[htzh]

@edreamleo I hope you had a good sabbatical! Thanks for mentioning leoflexx. I just checked it out. While flexx seems quite magical the app itself, as you said, seems just a prototype and not quite usable. For example there are no menus for Leo commands nor any other obvious ways to actually send commands to Leo. Browsing Leo outline seems to mostly work. Do you have any plan to actually make this approach work or are you suggesting this is a better alternative? If I understand it correctly the goal of flexx is to enable you to write UI code in Python instead of js. However if it does not directly enable Leo's existing UI code, i.e. one still needs to write a separate UI in python for the browser it seems just to let one use Python as a language choice. I still need to look into how leoflexx works exactly. Maybe you can give some quick pointers and set us on the right track.

[edreamleo]

@htzh The sabbatical is going well.

Yes, leoflexx.py is a prototype, but it does show how to access Leo's commands via Leo's bridge.

Iirc, the biggest problems involved key handling. Some browsers eat keys: leoflexx never sees them. I'm not sure what can be done. I forget how leoflexx handles user key bindings.

At present, executing <Alt-x>cff<Return> crashes, possibly as the result of recent work with Leo's find commands.

[edreamleo]

@htzh @boltex Let me try to clarify my thoughts re Leo in a browser:

1. I have no attachment to leoflexx.py. Feel free to ignore it, or study it for ideas.

2. I have no plans to improve leoflexx.py significantly. The keystroke problems are above my pay grade.

3. I welcome other approaches to putting Leo in a browsers. I am glad you two are interested in the project.

[htzh]

@boltex Have you seen the Code Server project? They let you serve VSCode to the browser. I don't know how it works exactly. You may be able to figure that out faster than me.

Looking forward to your 1.0 release.

[edreamleo]

@htzh Wow :-)