ENB: Seconds thoughts about Trilium Notes

[Edward K. Ream]

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. 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, 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

[Thomas Passin]

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.

[Thomas Passin]

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.

Trilium's weaknesses

Trilium undervalues the power of text:

I think that Edward does not appreciate how often users want to use Leo as an Notebook as opposed to a writing tool.  For a notebook, one wants to include all kinds of material, text and graphics, and then look at and read it many times.  For writing, developing code, and so on one mostly wants to edit and read text. Trillium by default, it seems to me, shows you a rendered view of its nodes and makes it harder to edit and work with the content.  Leo makes it easy to edit and work with text, but harder to insert and look at rendered graphics, etc.

An example is those Mermaid diagrams.  Leo can't currently use Mermaid, but it can create and render Plantum diagrams, which are somewhat similar, using VR3 with Asciidoc.  It's necessary to install a stand-alone Asciidoc engine with the right plugins, but it's very feasible.  Once created, I at least would like to see a series of diagrams rendered.  The text view would be useless, and it's unlikely I would be changing the diagrams once perfected.  Seeing the textual source would be a distraction.

Think about how Jupyter notebooks are usually used.  It's great to be able to develop your code in one, complete with graphics and notes.  But once developed, they are generally shared as a set of HTML  files, and only looked at not edited.  VR3 can display those files using an @jupyter node type.  Any text display would only show the raw html, which is essentially useless and distracting to look at.

[Edward K. Ream]

On Fri, Apr 26, 2024 at 8:02 AM Thomas Passin wrote:

>> 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. 

Surely this can be done w/o Terry's Easter Egg.

> 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.

I'm interested in an easy prototype. It doesn't have to be perfect.

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; 

Yes, that's similar to what I was thinking.

I envisage different nodes per each kind of node that VR or VR3 can handle.

That's what I meant by VR-related nodes.

Summary

We agree on enough to continue our conversation :-)

Edward

[Thomas Passin]

On Friday, April 26, 2024 at 1:13:38 PM UTC-4 Edward K. Ream wrote:

On Fri, Apr 26, 2024 at 8:02 AM Thomas Passin wrote:

>> 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. 

Surely this can be done w/o Terry's Easter Egg.

I wouldn't call it an Easter Egg, exactly, because it's not really hidden.  But it's awkward to use.  It seems to me that whatever command is called by the final splitter menu selection - if we can figure out what it is - should be callable by some other means.  I'd rather do that than mess with the VR3 code at this stage.  BTW, you can open a standard body editing pane as a separate window in the same way.

[Edward K. Ream]

On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin <tbp1...@gmail.com> wrote:

>> Trilium undervalues the power of text:

> I think that Edward does not appreciate how often users want to use Leo as a Notebook...

I agree. Leonistas should be able to use lots of graphics :-) That's why improving the VR plugins and (maybe) the rst3 plugin seems like a good idea.

> Trillium...shows you a rendered view of its nodes and makes it harder to edit and work with the content.

> Leo makes it easy to edit and work with text, but harder to insert and look at rendered graphics, etc.

That's a reasonable summary. A floating VR pane would be a step forward.

> VR3 can display [jupyter] files using an @jupyter node type. Any text display would only show the raw html...

Yes, sometimes the rendered view is preferable. But that's no reason to complicate Leo's interface.

Summary

The Easter Egg is the only way to expand the VR pane. An optional floating VR window would solve that problem.

Edward

[Thomas Passin]

On Friday, April 26, 2024 at 7:45:11 AM UTC-4 Edward K. Ream wrote:

Trilium emphasizes graphics throughout.

I particularly like the demo of Mermaid Diagrams. 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, so Leo's VR plugins could support Mermaid too.

VR3 can already support Mermaid diagrams with just a little bit of boiler plate.  It would be very easy to write some code to get rid of the boilerplate altogether.  See attached screen shot. 

I don't think that python-mermaid project has much value for this kind of diagram  It just translates some Python data structures to Mermaid declarative text, which the Mermaid machinery then renders outside of Python.  For hand authoring, the declarative text is easier and less trouble prone.  The data structure approach is good for cases where you want to render some node structures programatically, like a family tree, for example.

[Jacob Peck]

Why would a floating window solve any problems here?  How are you envisioning that a floating VR3 window, which can already be done today without any additional coding, would help the situation?

As a counterpoint, I only have a single display available to me.  I generally do my work (in Leo) on a single desktop monitor, or a tiny laptop screen.  In both cases I would much prefer a switchable pane, rather than a floating window.  The current solution of VR eating up a third of the screen by default, or of faffing about with a floating window (even more irksome on a laptop with a touchpad), is such a poor UX that I avoid it. Enough so that I've effectively stopped using Leo for anything that needs to be rendered.

Adding a first-class 'floating window' feature to VR/3 wouldn't fix any issues.  It would strictly exacerbate the issue.  But a context-aware switchable tab, which is eminently doable, would solve every single one of my personal problems.  And I know it's a workable solution because I've done it.

Leo is, to me, an editor, an IDE, and a platform.  But it is increasingly not an authoring tool for me, because of the current implementation of VR.  And that's frustrating, because authoring any sort of complex documentation should be where Leo shines, given the first-class outlining and clones.

Just my $0.02.  I wish we wouldn't just discard things out of hand because of perceived 'dubiousness'.  Experimentation is fruitful, and painless, given git branching.

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/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%40mail.gmail.com.

[Thomas Passin]

I'm with you here.  Between VR3 and Freewin, I've tried floating windows, new frames, and rendering into a tab in the log frame.  Freewin has a switchable display (edit <-> render) and I find that convenient and easy to work with, even without a way to set the default to render. Having the body pane display style be switchable would work very well for me as a UI, should not be hard to implement, and would not preclude any of those other display modes.

[Thomas Passin]

To illustrate one way I've used Leo as a notebook, here's a project authored in ReStructured Text, rendered by VR3, exported to HTML, and saved as a package by my browser.  Unzip the file and load the resulting html file into a browser.  There is a long data table in the middle but scroll past it and you will see some embedded graphs.  The Python code was run using VR3's code execution ability.

The same notebook could have been written using Markdown or Asciidoc.

On Friday, April 26, 2024 at 1:52:49 PM UTC-4 gates...@gmail.com wrote:

... 

[Thomas Passin]

On Friday, April 26, 2024 at 1:31:41 PM UTC-4 Edward K. Ream wrote:

The Easter Egg is the only way to expand the VR pane. An optional floating VR window would solve that problem.

Here you go:

ns = c.free_layout.get_top_splitter()
ns.open_window('_leo_viewrendered3')

 

[Edward K. Ream]

On Fri, Apr 26, 2024 at 2:38 PM Thomas Passin wrote:

The Easter Egg is the only way to expand the VR pane. An optional floating VR window would solve that problem.

Here you go:

ns = c.free_layout.get_top_splitter()
ns.open_window('_leo_viewrendered3')

Wow. Thanks for this.

And thanks for all the comments. They have all been helpful.

Let me summarize the discussion so far:

- I'm convinced. Replacing the body pane is a preference worth considering.

- That preference should also allow opening the VR pane as a separate window.

- A modular architecture for the VR pane (including VR3) is a separate issue.

I'm interested in both issues, but neither is an urgent priority.

Let's continue this fruitful discussion!

Edward

[Matt Wilkie]

>Trilium's weaknesses:

>There is no minibuffer and no way to execute commands by name. 

 True, but not fundamentally blocked. In the Awesome Trilium list is a js plugin for adding a command-palette. I imagine it's modelled after vs-code's Ctrl-Shift-P type-name-looking-for.

>There are no menus! Instead, small icons must suffice

 yeah, I'm not so fond of there being no menu at all. Mitigating that a bit is the F1 popup quick reference for the most used keyboard shortcuts. It is excellent.

Trilium can not create external files. Unless I am mistaken, one can only export nodes.

Yes, a big difference and a lack from my perspective.

Fundamental differences (observed so far):

Leo is plain text first, and achieves rich text and media by rendering. Trilium is rich text and media first, with the primary entry mechanism through the 3rd party CKEditor which saves as html. This is the foundational split behind the whole VR and multiple panes (pains? heheh) vs single pane thinking and attendant mitigation machinery. Trilium doesn't have to think about rendering hardly at all, since it's the embedded browser that does that.

Leo uses the file system for storage and Trilium uses sqlite. This gives Leo its external files extended abilities very nearly for free. For Trilium to adopt such features would be an exercise of some effort. Otoh, being able to run sql queries across all nodes can't be anything but powerful. (In Trilium access the SQL Console via Alt-0 or the flower logo at top left; yeah, speaks to lack of menu). 

It's this db backend which enables syncing one's entire KB across all devices in a pretty much set-and-forget manner. It's almost as good as Fossil SCM in this regard. This is very, very attractive.

Another Trilium limit: there's only a single knowledge database. ALL your Trilium work is one place. There is discussion on a future with multiple db but nothing substantive that I've seen. I'm new to the space and might be missing the action though.)

-matt

 

--

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/CAMF8tS2UMXdzzfz2jvCRzQj8x6NRRF4yoK_OjEedFfkJ5dG0UA%40mail.gmail.com.

[Edward K. Ream]

On Friday, April 26, 2024 at 2:50:16 PM UTC-5 Edward K. Ream wrote:

> I'm convinced. Replacing the body pane is a preference worth considering.

See #3892. The corresponding PR will make minimal changes to Leo's core and the VR and VR3 plugins.

Your comments, please.

Edward

[Thomas Passin]

It is possible to try out having VR/VR3 display in the same frame as the body editor.  You can get them both into the Log frame.  It's not perfect because anytime there is a message to the log, the view changes away from the body or rendered view to the Log pane. Also you can't use the Find or Nav panes and still see the body editor at the same time.  But it's kind of a prototype.

Here is how I set this up. There may be other ways. First, open the splitter context menu by either right-clicking on one of the splitter bars or from the Window menu.  Click on Open Window and select Body. A new free-floating window will open with the body editor.  Close this new window.  The body editor will reappear in the Tab pane.  Do the same thing with VR or VR3, whichever you have enabled. - open a new window with it, then close that window.  Or, if you are using VR3, issue the Minibuffer command vr3-toggle-tab instead.

If the log pane appears after this in the same frame as the tree, then use the splitter context menu Toggle Split Direction to get it side-by-side with the tree's frame.

A screen shot illustrating this layout is attached

[Thomas Passin]

Once you have got this layout set up, you can save it, which makes it simple to apply it to any outline after that.

[Edward K. Ream]

On Sun, Apr 28, 2024 at 1:43 PM Thomas Passin <tbp1...@gmail.com> wrote:

It is possible to try out having VR/VR3 display in the same frame as the body editor.  You can get them both into the Log frame. 

...

A screen shot illustrating this layout is attached.

Many thanks for all your comments. The design is becoming simpler.

I have just done the following:

- #3892 now pertains only to VR. The issue suggests adding only two commands to VR.

- #3887 now pertains only to VR3. I have assigned the issue to you and given it a 6.7.9 milestone.

- As noted in a comment, I see no reason now to create a plugin architecture for VR/VR3.

Edward

[Offray Vladimir Luna Cárdenas]

Hi,

On 26/04/24 11:49, Thomas Passin wrote:

I think that Edward does not appreciate how often users want to use Leo as an Notebook as opposed to a writing tool.  For a notebook, one wants to include all kinds of material, text and graphics, and then look at and read it many times.  For writing, developing code, and so on one mostly wants to edit and read text. Trillium by default, it seems to me, shows you a rendered view of its nodes and makes it harder to edit and work with the content.  Leo makes it easy to edit and work with text, but harder to insert and look at rendered graphics, etc.

[...]

Think about how Jupyter notebooks are usually used.  It's great to be able to develop your code in one, complete with graphics and notes.  But once developed, they are generally shared as a set of HTML  files, and only looked at not edited.  VR3 can display those files using an @jupyter node type.  Any text display would only show the raw html, which is essentially useless and distracting to look at.

Regarding taking inspiration from other tools that try to develop code in another way, bridging the gap between code, graphics, prose and other representations, Lepiter, brings several views of the same or of specialized information, as you can see in the tour[1]. And regarding the notebooks publishing format, that can be used to be viewed *and* edited, in contrast with HTML or ipynb that favor one or the other, respectively, our MiniDocs tool[2], brings some of the lessons learned while developing Grafoscopio[2a] since 2015/2016 to Lepiter (released on 2021). In [2b] you can find some advantages of the format combination we are using (Markdeep + STON) over more popular formats, like Jupiter's. In such format you can create pretty complete data stories like the ones in [3] and [3a].

BTW, Edward said some time ago and with a lot of justification something in the lines of how impressive it was that a tool like Pharo didn't have an advanced note taking system inside the tool. Now with Lepiter[1] this is being solved. And for the curious reader, the front page video presentation about the Glamorous Toolkit has been actualized in [4].

Cheers,

Offray

=== Links

[1] https://lepiter.io/feenk/introducing-lepiter--knowledge-management--e2p6apqsz5npq7m4xte0kkywn/
[2] https://code.sustrato.red/Offray/MiniDocs
[2a] https://mutabit.com/grafoscopio/index.en.html
[2b] https://mutabit.com/repos.fossil/mutabit/doc/tip/wiki/en/markdeep-extended--3t85t.md.html#appendix
[3] https://mutabit.com/repos.fossil/gig/doc/trunk/wiki/en/gig-portable-wiki--1apbv.md.html
[3a] https://mutabit.com/repos.fossil/mutabit/doc/trunk/wiki/en/petitparser-building-modular-parsers--ac8zq.md.html
[4] https://gtoolkit.com/

[Offray Vladimir Luna Cárdenas]

Hi,

On 26/04/24 16:36, Matt Wilkie wrote:

Leo is plain text first, and achieves rich text and media by rendering. Trilium is rich text and media first, with the primary entry mechanism through the 3rd party CKEditor which saves as html. This is the foundational split behind the whole VR and multiple panes (pains? heheh) vs single pane thinking and attendant mitigation machinery. Trilium doesn't have to think about rendering hardly at all, since it's the embedded browser that does that.

Leo uses the file system for storage and Trilium uses sqlite. This gives Leo its external files extended abilities very nearly for free. For Trilium to adopt such features would be an exercise of some effort. Otoh, being able to run sql queries across all nodes can't be anything but powerful. (In Trilium access the SQL Console via Alt-0 or the flower logo at top left; yeah, speaks to lack of menu). 

It's this db backend which enables syncing one's entire KB across all devices in a pretty much set-and-forget manner. It's almost as good as Fossil SCM in this regard. This is very, very attractive.

Another Trilium limit: there's only a single knowledge database. ALL your Trilium work is one place. There is discussion on a future with multiple db but nothing substantive that I've seen. I'm new to the space and might be missing the action though.)

-matt

In Grafoscopio's case (Grafoscopio is becoming a distribution of several extensions and customizations over Pharo/GToolkit) we are kind of in the middle, maybe because we were inspired by Leo and Pharo/Smalltalk. For example:

1.  our default UX/UI uses GToolkit's Lepiter to combine several representations (prose, code, data, graphics), 

2. our storage format kind of inverts what we had previously with the early Grafoscopio version: instead of Markdown inside a STON[1], which give us a pretty light and readable textual format (see the source code of Grafoscopio manual[1a], now we have STON metadata inside Markdeep, which keeps the readability, while providing a format that can be rendered in almost any web browser.

3. For storage, sharing, versioning and publishing of our notebooks we use Fossil.

Cheers,

Offray

[1] https://book.huihoo.com/smalltalk/pharo/enterprise-pharo/book-result/STON/STON.html
[1a] https://mutabit.com/repos.fossil/grafoscopio/file?name=Docs/En/Books/Manual/manual.ston&ci=tip