A Leo relative in the wild: Trilium Notes

[Matt Wilkie]

Hello Leonistas,

I've been exploring a program the last few weeks that seems like it might be an answer to a long felt wish: to have a Leo-like experience for editing and managing a rich text and media notes knowledgebase. That program is Trilium Notes. It's the only application I've encountered that uses clones in the same sense Leo does and is rooted in a tree, branch, and node hierarchy graph. It also has executable nodes (scripting), though unfortunately for my preferences not in python. (Oh well, one can't ever have it all, right? ;-) I haven't had this much fun playing with and learning a new software program since encountering Leo I-can't-remember-how-many years ago.

I'm encountering Trilium at an awkward moment in its life: just as the primary author is stepping aside. That said, there's a large and enthusiastic community which has formed Trilium Next to carry things on. At present they don't seem to have a gravity center -- imagine twenty people standing at a doorway emitting "oh no dear madam, after you" -- I believe/hope this will get sorted soon though.

I don't know if there will come a day when Leo and Trilium share more than some key architectural and function design decisions, but I figure at least the communities should be aware of each other. (I'll be composing a similar "hey did you know about Leo?" message for the Trilium folks too).

Felix, you might be interested to know that Trilium is written in javascript and the major effort at the moment is converting it to typescript. They seem to be blazing along on that front. Perhaps there are some tools or libraries that could be extracted/shared.

cheers,

-matt

 (from away)

[Edward K. Ream]

On Wed, Apr 24, 2024 at 2:57 PM Matt Wilkie <map...@gmail.com> wrote:

Hello Leonistas,

I've been exploring a program the last few weeks that seems like it might be an answer to a long felt wish: to have a Leo-like experience for editing and managing a rich text and media notes knowledgebase. That program is Trilium Notes.

Thanks for the link, Matt.

Trillium looks both very similar and very different from Leo :-)

Edward

[Christoph]

I am under the impression that CherryTree
(https://www.giuspen.net/cherrytree/) has implemented something similar
recently:
https://github.com/giuspen/cherrytree/issues/1222
Not sure if it is exactly the same or a variant. Also, Zotero has a
similar mechanism.
Of course, dealing with hierarchical data sooner or later requires a
mechanism that allows to put data in more than one branch of the
hierarchy so this seems to be a logical step. However, Leo has taken
this step more than 20 years ago and made it its fundamental design feature.

C.

On 4/24/24 21:57, Matt Wilkie wrote:
> Hello Leonistas,
>
> I've been exploring a program the last few weeks that seems like it might
> be an answer to a long felt wish: to have a Leo-like experience for editing
> and managing a rich text and media notes knowledgebase. That program

> is *Trilium
> Notes* <https://github.com/zadam/trilium>. It's the only application I've

> encountered that uses clones in the same sense Leo does and is rooted in a
> tree, branch, and node hierarchy graph. It also has executable nodes
> (scripting), though unfortunately for my preferences not in python. (Oh
> well, one can't ever have it all, right? ;-) I haven't had this much fun
> playing with and learning a new software program since encountering Leo
> I-can't-remember-how-many years ago.
>
> I'm encountering Trilium at an awkward moment in its life: just as the
> primary author is stepping aside. That said, there's a large and

> enthusiastic community which has formed *Trilium Next
> <https://github.com/TriliumNext> *to carry things on. At present they don't

[Edward K. Ream]

On Thu, Apr 25, 2024 at 3:49 AM Christoph <rho...@gmail.com> wrote:

Of course, dealing with hierarchical data sooner or later requires a
mechanism that allows to put data in more than one branch of the
hierarchy so this seems to be a logical step. However, Leo has taken
this step more than 20 years ago and made it its fundamental design feature.

And Leo has way better programming features, including c, g, p, generators, @others, @clean, and the Mulder/Ream update algorithm.

I'm not worried about competition, and Félix is several years ahead of would-be imitators.

Edward

[Thomas Passin]

Except that standard Leo nodes don't render graphics and other non-text items.  That's a big difference. We get around it to a degree with VR/VR3.  Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, we could overlay the rendering frame over the editing frame. We could switch in and out of rendering mode to allow editing.  I bet that wouldn't be too hard. One way would be to use a 2-frame tabbed widget.  Leo would then have no disadvantage compared with Trillium and its ilk, and would keep all of its advantages.

Yowee!

[Edward K. Ream]

On Thu, Apr 25, 2024 at 6:57 AM Thomas Passin <tbp1...@gmail.com> wrote:

Except that standard Leo nodes don't render graphics and other non-text items.  That's a big difference. We get around it to a degree with VR/VR3.  Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, we could overlay the rendering frame over the editing frame. We could switch in and out of rendering mode to allow editing.  I bet that wouldn't be too hard. One way would be to use a 2-frame tabbed widget.  Leo would then have no disadvantage compared with Trillium and its ilk, and would keep all of its advantages.

Yowee!

I'm interested. Let's see what you can do.

Edward

[Thomas Passin]

See new issue Allow VR/VR3-style rendering overlaid on standard editing nodes.

[Jacob Peck]

I actually implemented something similar in a private 'leoapp' (app that lives in a .leo file) I wrote for myself a few years back.  Pretty simple to get done, IIRC.

My general pattern was to have a controller class that contained two 'view' widgets (a QTextBrowser for rendered HTML, and a QTextEdit for editing).  The controller class had a wrapper widget that also had an 'edit' toggle button.  When 'edit' is clicked, a callback is fired off to remove the active view widget and replace it with the new one (and set some state in the controller so it doesn't lose track of things).  Content is updated between the two widgets whenever this swap happens.  Internally they are two completely different objects, but to the user, the swap is fairly seamless.

I did write this app relying on PyQt5, unfortunately, so I have a fair bit of updating to do if I want it to work on modern Leo.  Ah well.

Jake

--
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 on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2oz4FPGXyuztu8e%3DpA3_vLG3DCF2x24p1FM_kSrRPJKw%40mail.gmail.com.

[Thomas Passin]

This sounds pretty much what I had in mind.  The freewin plugin actually does the same (in its own separate window). VR/VR3 also replace the rendering widget type depending on what is to be rendered.  Currently VR3 can optionally render to a tab in the log frame instead of to a new frame within the overall Leo window.  So we're not far off.

[jkn]

Something like this, together with the 'paste a snippet as a file' feature I discussed a few weeks ago (and am still playing with) would go a long way to stopping me occasionally yearning for some of the features of Obsidian and/or Joplin, which I have tried recently.

[Edward K. Ream]

On Thursday, April 25, 2024 at 6:57:17 AM UTC-5 Thomas wrote:

Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, we could overlay the rendering frame over the editing frame. We could switch in and out of rendering mode to allow editing.  I bet that wouldn't be too hard.

Thomas, you may have solved a problem that has bedeviled me for ages! Here are my first thoughts:

I've never liked the VR pane. It seems like a significant waste of real estate.

Edit modes are confusing, but visual modes will work! Here are some preliminary thoughts:

Rendering modes

Both headlines and body text will specify a default rendering mode for each node:

- Headlines like @movie and @html (and all the others that VR and VR3 support) would set the default rending mode to some graphics mode.

- Otherwise, @language directives will specify the preferred rendering mode, usually text mode. However, @language rst would specify rst mode.

- A possibility: @rst-tree in the headline would specify that the rendered contents would consist of the node's body and the bodies of all descendant nodes.

Switching modes

The toggle-rendering-mode command will toggle between the default and alternate rendering modes. Text mode will always be one of those modes.

Users are unlikely to become confused about which mode is in effect because graphics look very different from text. If confusion does arise, graphics icons could mark graphics-capable nodes.

Summary

Rendering body text as either text or graphics seems like a natural idea. Why didn't I ever think of this before? And how did we ever live without it?

The toggle-rendering-mode command will toggle between graphics and text views.
Users are unlikely to become confused about what body panes contain. 

Rendering either text or graphics in the body pane:
- Significantly increases Leo's effective real estate.
- Promises to give Leo the visual capabilities of the most sophisticated outliners.

Today is a milestone in Leo's history. And there is further room for invention!

Edward

[Thomas Passin]

We are really on the same page here!

On Thursday, April 25, 2024 at 12:39:33 PM UTC-4 Edward K. Ream wrote:

On Thursday, April 25, 2024 at 6:57:17 AM UTC-5 Thomas wrote:

Hmm, instead of rendering those nodes in a separate frame as VR/VR3 does, we could overlay the rendering frame over the editing frame. We could switch in and out of rendering mode to allow editing.  I bet that wouldn't be too hard.

Thomas, you may have solved a problem that has bedeviled me for ages! Here are my first thoughts:

I've never liked the VR pane. It seems like a significant waste of real estate.

I completely agree about the real estate.  Almost always, I display VR3 renderings in a tab in the log pane just for this reason even though the view is smaller.  I have a button to toggle the VR3 tab on and off.  When off, the delay after each few keystrokes for rendering is not incurred, so the button gets used a lot.  BTW, whether in a separate frame or in a tab in the log frame, the VR3 display will update as you type.  The same is true in freewin if you toggle to the rendered view (you don't type into the freewin window, you type into the parent node in the main Leo window).

Edit modes are confusing, but visual modes will work! Here are some preliminary thoughts:

Rendering modes

Both headlines and body text will specify a default rendering mode for each node:

I have been thinking exactly this.  We have to make sure that the defaults do the right thing almost all the time so that people who don't care, and legacy outlines, work right without needing to change.

- Headlines like @movie and @html (and all the others that VR and VR3 support) would set the default rending mode to some graphics mode.

- Otherwise, @language directives will specify the preferred rendering mode, usually text mode. However, @language rst would specify rst mode.

Exactly; remember that VR3 can handle multiple (software) languages in a node (only one rendering language per node, though, i.e., RsT, Md, etc.).   It would be nice not to lose that ability.  VR3 can also execute the code in a node that has intermixed code and non-code sections.

- A possibility: @rst-tree in the headline would specify that the rendered contents would consist of the node's body and the bodies of all descendant nodes.

Tricky - a long subtree can incur too long a rendering time, or too much scrolling, especially when graphics are involved.  That's why VR3 has a menu item to render a subtree or only the current node.  I bet we could come up with a nearly painless way to do the same, but I have found that I want to sometimes see the node and sometimes the tree - so I don't think that @rst-tree is a good way to go.

Switching modes

The toggle-rendering-mode command will toggle between the default and alternate rendering modes. Text mode will always be one of those modes.

Users are unlikely to become confused about which mode is in effect because graphics look very different from text. If confusion does arise, graphics icons could mark graphics-capable nodes.

Agree. Again, most of the code we need is already working in VR3 and/or freewin.  Mainly we need to work out how to provide the overlay frame, and how to provide good user controls for switching between text and rendered views.

I assume that this capability will be built into the core, since it will involve multiple widgets where now there is only an editing widget. We should eventually make sure that there is an extension mechanism (via plugins) so that people can add new graphic renderings without needing to touch core Leo code.

From an architectural point of view, the current Leo editor widget could get replaced by a widget with several child widgets (a tabbed widget is one possibility), of which one is the current editor widget, and most keyboard and mouse input will go to it no matter whether the text or rendering widget is visible.  This plan would require minimal changes to the rest of Leo's code.

[Thomas Passin]

On Thursday, April 25, 2024 at 1:25:21 PM UTC-4 Thomas Passin wrote:

From an architectural point of view, the current Leo editor widget could get replaced by a widget with several child widgets (a tabbed widget is one possibility), of which one is the current editor widget, and most keyboard and mouse input will go to it no matter whether the text or rendering widget is visible.  This plan would require minimal changes to the rest of Leo's code.

Once we have such a widget,  VR3 could render right to it, just as it does now to a log pane tab. VR3 may not be exactly what we want to end up with in the long run, but going this route would very quickly give us a working prototype to get experience with.  The approach is to make the rendering widget in the new node display widget be VR3's rendering widget.

[Thomas Passin]

We already have such a widget and all the machinery we need!  It's the Log frame.  We create a frame like the Log frame but with the LeoQt edit widget instead of the Log widget.  We put this frame into the location that currently holds the edit widget.  We use the same technique to insert the VR3 widget into the Log frame but instead we put it into the new Edit/Render frame.  This would require no changes to VR3 or the LeoQt edit widget.

If all goes well we could even have a prototype working in hours, or days at the most.  Most of the work would be in constructing the Edit/Render frame (based on the Log frame), and setting it up when a commander is constructed.

[Matt Wilkie]

Wow. I thought/hoped saying a couple words about Trilium would spark a few thoughts, but nothing like the way this thread is running. It's amazing. Thanks all!

[Félix]

> Felix, you might be interested to know that Trilium is written in javascript and the major effort at the moment is converting it to typescript. They seem to be blazing along on that front. Perhaps there are some tools or libraries that could be extracted/shared.

Thank you Matt for bringing this to my attention! :D

Félix