My current project

[Félix]

After doing a few experiments with HTML+web based Leo outline viewers (and realizing that for a relatively large tree, the rendering needs virtualization of a subset of the visible nodes only, and that having DOM elements for ALL nodes of  the outline destroys performance!)

I've decided to put docutils-ts on the side for the next few days: I'll be working on another javascript version of Leo that will be web based, but opposite to LeoJS it is NOT embedded in vscode, nor will it edit files directly on github. 

It will instead allow for usage with local files on a computer or even even imported directly from a github repo or anywhere else, but will save/write files to local files on the computer.

But since being web based (i.e. in the browser) it needs permission for individual file access.

This implies that after opening a Leo file, to then import or write external files it will be required to 'right-click' on a node and choose 'write external file' / 'Refresh-from-disk' on any @<file> node you want refreshed / written. (it would not be automatic upon save/load of an outline) 

(maybe I can get the permission per folder instead - we'll see)

For now It's at the tech demo stage: I've not yet reused LeoJS implementations of the proper classes (vnodes, positions, commander, etc.) It' just a dummy/dumbed-down acyclic graph engine under the hood while I finalyse the GUI implementation, keyboard+mouse interactions. (It will of course use the same LeoJS classes sources after that's done)

What's the main benefit ? -> That GUI is quick and responsive like the original Leo! 

... and it's a cool weekend project! (link and github repo coming soon)

Félix

[Félix]

addendum: The current dummy/dumbed-down acyclic graph engine that I'm using for the preliminary UI tech is so small that it would be perfect for a self-contained read-only Leo outline viewer, which was the idea that Brian brought into light in that other thread (thanks to him for that!)

So prior to that real implementation mentioned in the above post, I'll make an exporter script available that will wrap/export any outline into a self contained HTML file, making the outline into a browsable 'read-only' Leo 'simulator', with zero-install.

Félix

[Thomas Passin]

Wow, great project!

[Edward K. Ream]

On Sat, Sep 13, 2025 at 11:23 PM Félix <felix...@gmail.com> wrote:

> ...for the next few days: I'll be working on another javascript version of Leo that will be web based, but opposite to LeoJS it is NOT embedded in vscode, nor will it edit files directly on github. 

> For now It's at the tech demo stage: ...

>It' just a dummy/dumbed-down acyclic graph engine under the hood while I finalyse the GUI implementation, keyboard+mouse interactions. (It will of course use the same LeoJS classes sources after that's done)

> What's the main benefit ? -> That GUI is quick and responsive like the original Leo! 

> ... and it's a cool weekend project! (link and github repo coming soon)

I approve of quick demos. Happy coding!

Edward

[Offray Vladimir Luna Cárdenas]

Hi Felix,

Maybe this is vaguely related, but now that you are exploring alternative paths to HTML+web you could consider Hypermedia Systems[1] like HTMX[2] or Data-star[3].

[1] https://hypermedia.systems/
[2] https://htmx.org/
[3] https://data-star.dev/ 

Of course you're a pretty fluent programmer of JS and TS, and while none of those frameworks are anti-JS, for me at least has been a breath of fresh air to see alternatives to develop web interactive interfaces without all the incidental complexity of the JS framework of the week and JS in general (I "just" needed to wait a couple of decades to have a sensible alternative ;-) ). 

Now that you're in your exploring phase, it maybe worth to take a look at these alternative approaches that do not virtualize the DOM or use JSON as a primary format and instead do things in the server with the "old and good" hypermedia approach.

Cheers,

Offray  

--
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 view this discussion visit https://groups.google.com/d/msgid/leo-editor/4db4cc9b-19c8-41be-a43d-0e9b1a5746f6n%40googlegroups.com.

[Félix]

Thank you Vladimir for your suggestions. I will look into those shortly. :)

In the meantime, as you may have read in the other recent thread started by Brian about how to make an HTML read-only viewer for (Leo) outlines, I've made one myself. 

It is minimal and self contained (inline style and script, no external libraries nor bulky imports) - I have attached it here also just in case (copy its contained @button to your 'home/.leo/myLeoSettings.leo'  @settings/@buttons node and restart to try it out) 

Circling back to the main subject of this thread: 'My current Project' - I've changed my mind: I will not bring LeoJS classes into this new front-end outline viewer, I will do the opposite: I will bring it into LeoJS as an alternative UI so that the user will have the choice of the vscode's tree and body (with full vscode functionality) or this 'snappy and instant-reaction' tree and body. :)

Again, Let me know what you think if you have any ideas or comments about this, and please -> try out the attached demo if you have not already!! 

Félix

[Félix]

I've changed my mind again!

I'm going to integrate LeoJS's core classes into that small, self contained javascript UI!!

It's clearly the coolest thing to do! I don't even know what led me to think bringing that UI in LeoJS instead first was the best thing to do! 

So with that, people will be able to go to github/boltex/leo-web or whatever and bam! they'll be in a true 'Leo for the web' in their browser... 

Although, since browser based editors require granular permissions to edit local files, @files node will have to be right-clicked and commanded to 'Refresh from disk' to fill up and refresh themselves after opening a Leo file, instead of all being read from file upon opening like the original Leo.

(LeoJS didnt have this limitation because if it is used on the web, not locally, it's only for online repositories like on github which use a virtual file-system.)

So yeah, clearly a quick-loading, and tightly responsive browser-based 'leo for the web' without all the big vscode-editor attached to it, and also without .db nor .zip support to lighten the whole app would be the best thing to do with those core Leo classes that I converted from python to typescript for LeoJS! 

I'll keep you updated with a demo sometime soon :)

Félix

[Edward K. Ream]

On Friday, October 10, 2025 at 7:16:20 PM UTC-5 Félix wrote:

I've changed my mind again!

I'm going to integrate LeoJS's core classes into that small, self contained javascript UI!!

... 

So yeah, clearly a quick-loading, and tightly responsive browser-based 'leo for the web' without all the big vscode-editor attached to it, and also without .db nor .zip support to lighten the whole app would be the best thing to do with those core Leo classes that I converted from python to typescript for LeoJS! 

I'll keep you updated with a demo sometime soon :)

Sounds good!

Edward