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. *Leo's body pane* Yesterday, I proposed that Leo's body might contain either text (p.b) or graphics (the VR pane). I now think that's a dubious idea. Instead, the VR pane could (optionally) be a separate window. Swapping the contents of the body pane creates more problems than it solves: - The UI (and its rationale) becomes significantly more complex. There are hidden rules at work. - The UI prevents users from seeing both p.b and the VR pane simultaneously. Trilium sometimes works around this problem by showing the source and results in the same pane. - Leo's body pane is anchored and can't expand or move. Allowing the VR pane to be a separate window solves all these problems. *Trilium's strengths* Trilium emphasizes graphics throughout. I particularly like the demo of Mermaid Diagrams <https://mermaid.js.org/>. Mermaid is a Javascript project. Several vs-code plugins support such diagrams, so LeoInteg and LeoJS already have access to Mermaid Diagrams! The Python world has python-mermaid <https://pypi.org/project/python-mermaid/>, so Leo's VR plugins could support Mermaid too. *Trilium's weaknesses* Trilium undervalues the power of text: - There is no minibuffer and no way to execute commands by name. There are no menus! Instead, small icons must suffice. - Organizer nodes contain "preview cards" (my term) that show rendering descendant nodes. There is no obvious way to create text summaries of a sub-tree. - Trilium can not create external files. Unless I am mistaken, one can only export nodes. *Ideas worth emulating* Trilium nodes often show the "attached" css and Javascript. These views seem like the inverse of Leo's @button scripts. Some possibilities for Leo: -- A new *p.css* property. This property would contain css that modified the view of p.b or the VR pane. Setting this property might require a new UI element. -- A new *p.ui_script* property. This property might contain the rendering script in effect for the node. For security reasons, this property *must not* be settable. As discussed in a previous post, the VR plugins could render *@rst-tree* nodes using all the node's descendants. And Leo's rst3 command might support @graphics and other VR-related nodes. *A plugin-base VR architecture* Leo's existing VR and VR3 plugins are monolithic. Both plugins would benefit from a more modular organization. *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. - The VR pane could use a modular architecture based on plugins. I look forward to discussing this topic with Thomas. - Leo's rst3 command might support VR-related 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/36442543-525b-4ca1-8d86-9097c884f161n%40googlegroups.com.
