On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote: This Engineering Notebook post contains second thoughts about Trilium Notes.
*tl;dr:* Leo might add only *incremental *improvements inspired by Trilium Notes. All fundamental aspects of Leo will remain as they are. *Summary* *Changing the rendering of Leo's body pane is a dubious idea.* Instead: - As an option, the VR pane could become a floating window. This is already possible, at least with VR3. With VR3 enabled, right click on the boundary between two frames to get the splitter menu. Select *Window* then *VR3*. VR3 opens in a new floating window. Presumably if only VR were enabled you could do the same (untested). The whole procedure is a little awkward but presumably could be made to work from a command or button. [Aside - this capability is a tribute to the people who worked up the splitter mechanism (was that Terry Brown?). Plugins like VR3 were not written with any code to become free-floating windows, but the basic plugin mechanism automatically makes them available to the splitter machinery, which can do the job.] I have found that using a view like VR3 in a separate window is not as useful as I would like because window overlaps obscure too much. It would work fairly well with a very wide monitor. Freewin is also a freefloating window, and it can switch between text and rendered views, but the expected usage lends itself better to using several narrower windows next to the main Leo window. Freewin was intended mostly for comparing two nodes while being live with its underlying host node so that the host can be edited while looking at the comparison node. - The VR pane could use a modular architecture based on plugins. I look forward to discussing this topic with Thomas. VR/VR3 basically work in a way that could be more modularized, I would think. Basically, the plugin must: 1. Figure out what kind of node it is looking at, usually by page directives like *@language;* 2. Send the contents of the node or subtree to some appropriate code that transforms it into HTML; 3. Send the HTML to a rendering engine; This is normally the Qt WebEngine widget (for VR3) but could be something else. As an alternative, for a node with computer code the code can be extracted and sent to a code engine for execution. VR3 can collect and display or execute all the code chunks even if they are separated by non-code parts (so VR3 can do literate programming basically for free). - Leo's rst3 command might support VR-related nodes. I'm not sure just what this means - "VR-related nodes". VR3 can already render an rst tree because it can (optionally) render any subtree. So you can get an approximation of what your document will look like, including any graphics. I use this capability when I author a Sphinx document. It's very handy. But it is limited because some internal links and other features have to be created by Sphinx after the rst3 command has been issued so you can't get a fully complete rendering just from the Leo nodes. I welcome all comments. Edward -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/c81dac45-fec8-4f9b-9a31-6debcea505a4n%40googlegroups.com.
