*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 On Saturday, September 20, 2025 at 1:50:47 PM UTC-4 Félix wrote: > 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 > > On Monday, September 15, 2025 at 5:12:39 PM UTC-4 [email protected] wrote: > >> 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 >> >> >> On 9/13/25 23:23, Félix wrote: >> >> 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 >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/leo-editor/4db4cc9b-19c8-41be-a43d-0e9b1a5746f6n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/leo-editor/4db4cc9b-19c8-41be-a43d-0e9b1a5746f6n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/leo-editor/5df5ecce-a1fb-4869-84f1-a7e71a0b72fan%40googlegroups.com.
