Re: ENB: Seconds thoughts about Trilium Notes

[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=tip


--
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/80580625-b770-4d5d-9839-98d73d6d006c%40riseup.net.

Re: ENB: Seconds thoughts about Trilium Notes

[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/

--
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/260088c6-3724-4498-a0ab-fc3059fd190b%40riseup.net.

Re: ENB: Seconds thoughts about Trilium Notes

[Edward K. Ream]

On Sun, Apr 28, 2024 at 1:43 PM Thomas Passin  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

-- 
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/CAMF8tS3cT13tuBD%3DHF8TUJ64t85G9JNsCpouLOv2EfdGK0ApYg%40mail.gmail.com.

Re: ENB: Seconds thoughts about Trilium Notes

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

On Sunday, April 28, 2024 at 2:43:34 PM UTC-4 Thomas Passin 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.  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
>
> On Sunday, April 28, 2024 at 7:48:28 AM UTC-4 Edward K. Ream wrote:
>
>> 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
>>
>

-- 
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/582519a2-5a4c-4e7c-a3e2-ce58f1329924n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[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

On Sunday, April 28, 2024 at 7:48:28 AM UTC-4 Edward K. Ream wrote:

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

-- 
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/3bb6efc3-f2b2-480c-b8a8-7398355db595n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[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

-- 
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/e46da8a5-b107-4148-af81-21315e2a73f5n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[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



On Fri, Apr 26, 2024 at 12:50 PM Edward K. Ream  wrote:

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

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

Re: ENB: Seconds thoughts about Trilium Notes

[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

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

Re: ENB: Seconds thoughts about Trilium Notes

[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')
 

-- 
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/a9734be6-dc2c-44ee-adea-9310dead5cd3n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

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

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

> 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
>
> On Fri, Apr 26, 2024 at 1:31 PM Edward K. Ream  wrote:
>
>> On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin  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
>>
>> -- 
>> 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
>>  
>> 
>> .
>>
>

-- 
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/47847ae3-a0eb-45ef-993b-957beece1c2cn%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[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

On Fri, Apr 26, 2024 at 1:31 PM Edward K. Ream  wrote:

> On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin 
> 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
>
> --
> 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/CAMF8tS1WZmuDxfRg8vU-oWsXKRZOoKSqn2ZP0cGX0Duw_5ys4A%40mail.gmail.com
> 
> .
>

-- 
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/CAJ1i%2BSYr2DEPMRRaA9Xr%2BXdUx-a1r%2B%2Bj7Z0zxJ8LxTwTvG998Q%40mail.gmail.com.

Re: ENB: Seconds thoughts about Trilium Notes

[Edward K. Ream]

On Fri, Apr 26, 2024 at 11:49 AM Thomas Passin  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

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

Re: ENB: Seconds thoughts about Trilium Notes

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

-- 
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/64ab1c7c-3594-436a-847d-e61a1343bbe5n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

[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

-- 
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/CAMF8tS2L-jso6AQOmiegjUvxcTY-eM%3D4W5f%2By8%2BoOARgO6VBng%40mail.gmail.com.

Re: ENB: Seconds thoughts about Trilium Notes

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

-- 
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/6af83645-d756-4029-b1c4-5e4fa93f4db9n%40googlegroups.com.

Re: ENB: Seconds thoughts about Trilium Notes

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

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.