-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[proposal] Work with editor in browser #123
Comments
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! :) |
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. 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 |
Also in the long term freedom of the browser UI might allow more creative modes of interaction. Certainly integration with |
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. |
Does |
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 |
Yes leojs implements the leo functionality in typescript. (javascript). So indeed you are right, a server should run in python and offer remote capabilities. |
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. |
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 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. |
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. |
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. |
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. |
@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! |
@edreamleo I hope you had a good sabbatical! Thanks for mentioning |
@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 |
@htzh @boltex Let me try to clarify my thoughts re Leo in a browser:
|
@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. |
@htzh Wow :-) |
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.
The text was updated successfully, but these errors were encountered: