Leo 6.8.2 coming soon. Please test devel

[Edward K. Ream]

Thomas's excellent new layout code is now part of "devel".

I have tentatively scheduled Leo 6.8.2 for Friday, October 25. This date will give us all plenty of time to test the new layout code.

Edward

[Edward K. Ream]

On Wednesday, October 9, 2024 at 8:12:19 AM UTC-5 Edward K. Ream wrote:

I have tentatively scheduled Leo 6.8.2 for Friday, October 25.

I have just merged two more PRs into the "devel" branch.

I shall approve no further work on Leo 6.8.2 unless someone reports reversions against recent changes.

I'll leave the October 25 date unchanged so we may all test "devel" thoroughly. Please continue to do so.

Edward

[Viktor Ransmayr]

Hello Edward & Thomas,

Something is awkward with the current state of the new layout system ( at least in my Fedora Linux VM ;-)

I'm on the latest version of the 'devel' branch - and - I'm able to reproduce this behavior !

Here are the notes from my tests:

    Perform another test with plugins enabled:

    * # Starting with '@string initial-split-orientation = horizontal' from "myLeoSettings.leo" - plus -
    * # VR & VR3 enabled, i.e. VR3 should be prioritized.
    * Try 'layout-vertical-thirds' - OK? - No change ...
    * Try 'layout-horizontal-thirds' - OK? - Change to 'legacy' layout ...
    * Try 'layout-quadrant' - Not OK - No change to layout - but - w/o VR pane using VR3 ...
    * Try 'layout-restore-default' - OK? - No change to layout ...
    * Try 'layout-big-tree' - OK - Change to '?' layout with VR pane using VR3 ...
    * Try 'layout-restore-default' - OK? - Change to 'legacy' layout with VR pane using VR3 ...
    * Try 'layout-render-focused' - Not OK - The 'legacy' layout is kept - but - a fifth tile is added with another active (!) copy (?) of the body pane !
    * Try 'layout-swap-log-panel' - OK? -> 1 + 3 + 1 ...
    * Try 'layout-swap-log-panel' again - OK? -> 2 + 3 ...

Note: With "active (!) copy (?)" I mean that whatever I type in the original tile appears in the other tile as well.

With kind regards,

Viktor

[Viktor Ransmayr]

Hello Edward & Thomas,

Viktor Ransmayr schrieb am Montag, 14. Oktober 2024 um 14:02:34 UTC+2:

...

Something is awkward with the current state of the new layout system ( at least in my Fedora Linux VM ;-)

I'm on the latest version of the 'devel' branch - and - I'm able to reproduce this behavior !

Here are the notes from my tests:

    Perform another test with plugins enabled:

    * # Starting with '@string initial-split-orientation = horizontal' from "myLeoSettings.leo" - plus -
    * # VR & VR3 enabled, i.e. VR3 should be prioritized.
    * Try 'layout-vertical-thirds' - OK? - No change ...
    * Try 'layout-horizontal-thirds' - OK? - Change to 'legacy' layout ...
    * Try 'layout-quadrant' - Not OK - No change to layout - but - w/o VR pane using VR3 ...
    * Try 'layout-restore-default' - OK? - No change to layout ...
    * Try 'layout-big-tree' - OK - Change to '?' layout with VR pane using VR3 ...
    * Try 'layout-restore-default' - OK? - Change to 'legacy' layout with VR pane using VR3 ...
    * Try 'layout-render-focused' - Not OK - The 'legacy' layout is kept - but - a fifth tile is added with another active (!) copy (?) of the body pane !
    * Try 'layout-swap-log-panel' - OK? -> 1 + 3 + 1 ...
    * Try 'layout-swap-log-panel' again - OK? -> 2 + 3 ...

Note: With "active (!) copy (?)" I mean that whatever I type in the original tile appears in the other tile as well.

One small - but - maybe important addition to the 'Note':

* The original tile also 'has' line numbers, which the other tile does not have.

With kind regards,

Viktor

[Edward K. Ream]

On Mon, Oct 14, 2024 at 7:02 AM Viktor Ransmayr <viktor....@gmail.com> wrote:

> Something is awkward with the current state of the new layout system ( at least in my Fedora Linux VM ;-)

Many thanks, Viktor, for your testing.

I'm willing to delay 6.8.2 if necessary to make sure layouts "just work".

Thomas, please take a look.

Edward

[Thomas Passin]

I think this is happening because of a minor mismatch between the previous layout system - the one that required outlines to be reload to change the layout - and the new one that I wrote.  The old ones are applied when the outline is being loaded. The layout can be changed (and the outline reploaded) just as in 6.8.1.  The new ones can be applied by the layout-* commands at any time.There are two things in play:

1. I overlooked the initial-split-orientation setting, and my layouts don't make use of it.  They were created to look like the layout diagrams that Edward included in docstrings. I personally find the setting confusing because for many layouts I have no idea what the result would be.

2. Some of the 6.8.1 layouts are created with VR already them.  It won't display until you show V with one of the commands like 'vr', 'vr-show', 'vr-toggle' but the splitter panel may show.  That assignment is not conditional on VR/VR3 enablement. Now if you, say, toggle VR3 but the layout has no spot for it, it will be inserted into the main splitter next to whatever was there before. That way you can end up with both VR and VR3 and they will probably be next to each other.  It's pretty obvious when VR3 displays the body, but it's not always obvious with VR.  The panel you mention that did not have line numbering, that would be VR showing the body.

The plan has been to move away from the 6.8.1 system to the new one as we gain experience and see if it needs any changes. This initial-split-direction business is one we will need to work out how to handle, or if it should be retired altogether.

[Edward K. Ream]

On Mon, Oct 14, 2024 at 7:48 AM Thomas Passin <tbp1...@gmail.com> wrote:

I think this is happening because of a minor mismatch between the previous layout system - the one that required outlines to be reload to change the layout - and the new one that I wrote. 

Many thanks, Thomas, for this detailed analysis.

The plan has been to move away from the 6.8.1 system to the new one as we gain experience and see if it needs any changes. This initial-split-direction business is one we will need to work out how to handle, or if it should be retired altogether.

My vote would be to retire initial-split-direction. The new layouts probably cover both values of this setting. If a new layout is needed, then so be it.

In this regard, initial-split-direction is like an unwanted kwarg. Or so I think now.

Edward

[Thomas Passin]

I'm not sure it's worth delaying 6.8.2 but OTOH I don't see a compelling need to get 6.8.2 out. My feeling is that the 6.8.1 layout system is in there intact and the new layout commands are optional for the user.  They are more convenient and don't require a reload of the outline so they bring value.  The initial-split-orientation is likely to be very confusing for users.  It even confuses me.  Are both the main and secondary splitters going to have their orientation changed? if not, which one?  And how many users are even going to know what a splitter is, let alone which widgets are in which splitters, and what the "orientation" indicates? In addition, changing the splitter orientations is only going to confuse and muddle the starting orientation. It will only be useful for a few of them.

I think that if we want layouts with different orientations, we should just create them and offer them to the user, for those layouts it makes sense for. Do you want to delay 6.8.2 until we do that?  You would have to create them for the 6.8.1 layouts, and I would have to create them for the new system.

I also think we should devise as way for the user to know what they will be getting if they change the default layout.  With the new layouts, at least it's easy enough to switch between them until one finds one he likes.

[Edward K. Ream]

On Mon, Oct 14, 2024 at 7:59 AM Thomas Passin <tbp1...@gmail.com> wrote:

> I'm not sure it's worth delaying 6.8.2 but OTOH I don't see a compelling need to get 6.8.2 out. 

Let's get this done. There is no point in procrastination.

> My feeling is that the 6.8.1 layout system is in there intact and the new layout commands are optional for the user.  They are more convenient and don't require a reload of the outline so they bring value.  The initial-split-orientation is likely to be very confusing for users.  It even confuses me.  Are both the main and secondary splitters going to have their orientation changed? if not, which one?  And how many users are even going to know what a splitter is, let alone which widgets are in which splitters, and what the "orientation" indicates? In addition, changing the splitter orientations is only going to confuse and muddle the starting orientation. It will only be useful for a few of them.

All good questions. So let's do whatever is necessary to retire the setting relating to initial split direction.

> I think that if we want layouts with different orientations, we should just create [new layouts] and offer them to the user.

That was my thinking exactly.

> Do you want to delay 6.8.2 until we do that?

Yes!

> You would have to create them for the 6.8.1 layouts, and I would have to create them for the new system.

I'm willing.

> I also think we should devise a way for the user to know what they will be getting if they change the default layout.  With the new layouts, at least it's easy enough to switch between them until one finds one he likes.

Afaik, all layout commands have docstrings with layout diagrams. Those diagrams should suffice.

There will be less confusion when all layouts are immutable. (Not affected by settings).

Edward

[Viktor Ransmayr]

Hello Edward & Thomas,

tbp1...@gmail.com schrieb am Montag, 14. Oktober 2024 um 14:59:06 UTC+2:

On Monday, October 14, 2024 at 8:43:41 AM UTC-4 Edward K. Ream wrote:

On Mon, Oct 14, 2024 at 7:02 AM Viktor Ransmayr <viktor....@gmail.com> wrote:

> Something is awkward with the current state of the new layout system ( at least in my Fedora Linux VM ;-)

...

I'm not sure it's worth delaying 6.8.2 but OTOH I don't see a compelling need to get 6.8.2 out. My feeling is that the 6.8.1 layout system is in there intact and the new layout commands are optional for the user.  They are more convenient and don't require a reload of the outline so they bring value.  The initial-split-orientation is likely to be very confusing for users.  It even confuses me.  Are both the main and secondary splitters going to have their orientation changed? if not, which one?  And how many users are even going to know what a splitter is, let alone which widgets are in which splitters, and what the "orientation" indicates? In addition, changing the splitter orientations is only going to confuse and muddle the starting orientation. It will only be useful for a few of them.

I think that if we want layouts with different orientations, we should just create them and offer them to the user, for those layouts it makes sense for. Do you want to delay 6.8.2 until we do that?  You would have to create them for the 6.8.1 layouts, and I would have to create them for the new system.

I also think we should devise as way for the user to know what they will be getting if they change the default layout.  With the new layouts, at least it's easy enough to switch between them until one finds one he likes.

To add a bit more context from my side:

* The "@string initial-split-orientation = horizontal" is not a new - but - a quite old configuration setting.

* --> I believe at least 4 to 5 years old. - In my Fedora VM I have it as a 'left-over' defined in the "myLeoSettings" outline, while in my Debian VM it is taken (w/o any explicit action on my side) from the "leoSettings" outline

I also believe that we should not forget the ~ layout & theming ~ experience offered to first-time Leo users in their 'workbook' outline.

This is something, that I plan to look at next (w/o waiting for any changes to the current layout system implementation) ...

With kind regards,

Viktor

[Thomas Passin]

On Monday, October 14, 2024 at 10:07:48 AM UTC-4 Edward K. Ream wrote:

On Mon, Oct 14, 2024 at 7:59 AM Thomas Passin <tbp1...@gmail.com> wrote:> I also think we should devise a way for the user to know what they will be getting if they change the default layout.  With the new layouts, at least it's easy enough to switch between them until one finds one he likes.

Afaik, all layout commands have docstrings with layout diagrams. Those diagrams should suffice.

I think it's similar to the keybindings display.  Theoretically a user could keep executing the help-for-keystrokes command until they found what they want.  But Leo provides a menu item that displays a fairly readable list of all of them. Most users are not going to think about looking at docstrings, and if they did they might not realize that the associated command names can be seen (but not copied) in the Plugins menu, and if they did they might not connect those names with using F11.  If they did get to the F11 stage, they would have to laboriously try one layout command after another, and remember the last ones as they went.  It's just too hard.

I think a menu item like /Settings/Show Settings/Show-Layouts that showed all those docstrings in a tab would be very helpful and right in line with what we already do  with bindings, commands, etc.

[Thomas Passin]

On Monday, October 14, 2024 at 10:37:56 AM UTC-4 viktor....@gmail.com wrote:

Hello Edward & Thomas,

I also believe that we should not forget the ~ layout & theming ~ experience offered to first-time Leo users in their 'workbook' outline.

I completely agree, and I will welcome your thoughts on what layouts should be used for a first-time user and the workbook tab. Of course, not everyone will like the same starting layout (I like the new "fallback-layout", but I believe Edward prefers another one, for example) but the default initial layout should be very readable and easy to work with.

[Edward K. Ream]

On Mon, Oct 14, 2024 at 9:37 AM Viktor Ransmayr wrote:

> we should not forget the ~ layout & theming ~ experience offered to first-time Leo users in their 'workbook' outline.

I agree completely. Thanks for your testing!

Edward

[Edward K. Ream]

On Mon, Oct 14, 2024 at 9:39 AM Thomas Passin wrote:

I think a menu item like /Settings/Show Settings/Show-Layouts that showed all those docstrings in a tab would be very helpful and right in line with what we already do with bindings, commands, etc.

Excellent idea. Let's do it.

I've just created #4099 to keep track of our ideas and tasks. Please update this issue as you like.

Edward

[Edward K. Ream]

On Monday, October 14, 2024 at 9:39:29 AM Thomas wrote:

> I think a menu item like /Settings/Show Settings/Show-Layouts that showed all those docstrings in a tab would be very helpful.

I agree. I have just created PR #4102: "add show-layouts command and menu item".

This PR also improves the existing help-for-layouts command.

Thomas, please create a PR for your actual work on layouts. We should be able to work on our separate PRs without interference.

Edward

[Viktor Ransmayr]

Hello Edward & Thomas,

Viktor Ransmayr schrieb am Montag, 14. Oktober 2024 um 16:37:56 UTC+2:

tbp1...@gmail.com schrieb am Montag, 14. Oktober 2024 um 14:59:06 UTC+2:

On Monday, October 14, 2024 at 8:43:41 AM UTC-4 Edward K. Ream wrote:

On Mon, Oct 14, 2024 at 7:02 AM Viktor Ransmayr <viktor....@gmail.com> wrote:

> Something is awkward with the current state of the new layout system ( at least in my Fedora Linux VM ;-)

...

To add a bit more context from my side:

* The "@string initial-split-orientation = horizontal" is not a new - but - a quite old configuration setting.

* --> I believe at least 4 to 5 years old. - In my Fedora VM I have it as a 'left-over' defined in the "myLeoSettings" outline, while in my Debian VM it is taken (w/o any explicit action on my side) from the "leoSettings" outline

I also believe that we should not forget the ~ layout & theming ~ experience offered to first-time Leo users in their 'workbook' outline.

This is something, that I plan to look at next (w/o waiting for any changes to the current layout system implementation) ...

Here are the notes from my testing of the current layout system state in a ~ fresh ~ installation for a new Leo user:

* -> Leo is starting in '<which>' (" - | ") layout w/o a VR pane ...
* ==> Body pane of top-level 'Workbook' outline node is initially empty.
* ==> According to 'Running Leo' it should contain Leo’s cheat sheet and an example from the rst3 tutorial [1].
* Try 'layout-swap-log-panel' - OK? -> Change to (" | | ") layout w/o a VR pane ...
* Try 'layout-swap-log-panel' again - OK -> Change back to (" - | ") layout w/o a VR pane ...
* Try 'layout-legacy' - OK? -> Change to 'legacy' (" + ") layout with VR pane using VR as renderer ...
* ==> 'Legacy' layout is what's still shown in the screenshot for Leo's main window on the home page.
* Try 'layout-restore-default' - Confusing / OK? -> No layout change, i.e. still the 'classical' (" + ") layout with VR pane ...
* Try 'layout-big-tree' - OK -> Change to 'big tree' (" ? ") layout with VR pane ...
* Use 'layout-restore-default' to change back to 'legacy' (" + ") layout with VR pane ...
* Try 'layout-render-focused' - OK? -> Change to 'legacy' (" = | ") layout with VR pane ...
* Use 'layout-restore-default' to change back to 'legacy' (" + ") layout with VR pane ...
* Try 'layout-horizontal-thirds' - OK? -> Change to 'horizontal thirds' (" ? ") layout with VR pane ...
* Use 'layout-restore-default' to change back to 'legacy' (" + ") layout with VR pane ...
* Try 'layout-vertical-thirds' - OK? -> Change to 'vertical thirds #1' (" - | | ") layout with VR pane ...
* Use 'layout-restore-default' to change back to 'legacy' (" + ") layout with VR pane ...
* Try 'layout-vertical-thirds2' - OK? -> Change to 'vertical thirds #2' (" | - | ") layout with VR pane ...
* Use 'layout-restore-default' to change back to 'legacy' (" + ") layout with VR pane ...
* Try 'layout-quadrant' - Confusing / OK? -> No layout change, i.e. still the 'classical' (" + ") layout with VR pane ...

As you (Thomas) already stated in your initial reply to the problem found during my earlier tests:

• They do not happen here, because for a fresh installation only the 'viewrendered.py' plugin is enabled.

However these new test reveals the following about the layout commands:

• layout-legacy == layout-quadrant == layout-restore-default
  
• These commands are doing / providing the same layout !  - This is confusing ( at least for me ;-)

I do believe, that the number of layout commands in Leo's core should be reduced to a bare minimum - and - some others (e.g. like 'big tree' & 'vertical thirds #2) should at the most be documented

The selection of the minimal commands could be guided by the fact that most (all?) monitors have a rectangular  and not a square form.

With kind regards,

Viktor

---

[1] https://leo-editor.github.io/leo-editor/running.html#leo-s-workbook-file

[Thomas Passin]

I think you are right and that legacy and quadrant are the same. By coincidence I noticed that yesterday.  After double checking I will propose removing one of them.  layout-restore-default should restore the layout prescribed by the "qt-layout-name" setting, whatever it is.  I tested that yesterday as well, and it seems to work as intended.

 

I also found that my "fallback" layout is essentially the same as "vertical thirds", so we could remove the "fallback"  layout. I only put it in there to make sure I could get the one I preferred while we got all the rest of the new system worked out.

The selection of the minimal commands could be guided by the fact that most (all?) monitors have a rectangular  and not a square form

Ah, monitor aspect ratios! How often have I wished for a monitor with a greater height than width! The layouts I usually use have the greatest height for the body editor, and then for the tree.  I sometimes put special panes into the log frame,and then I need the log frame to have good height, as well.  I don't see how anyone can stand using a squat body editor or tree view.  But tastes differ.

[Viktor Ransmayr]

Hello Thomas,

tbp1...@gmail.com schrieb am Mittwoch, 16. Oktober 2024 um 15:50:16 UTC+2:

...

layout-restore-default should restore the layout prescribed by the "qt-layout-name" setting, whatever it is.  I tested that yesterday as well, and it seems to work as intended.

...

Is this  "qt-layout-name" setting already part of Leo's 'devel' branch - or - is it something local to your setup ?

I did not know about it - and - therefore (obviously) did not have any effect on my tests for a first installation of Leo ...

With kind regards,

Viktor

[Thomas Passin]

It's been there since 6.8.1.  Just one of those many things it's hard to know that Leo has. And yes, it's in devel as well. Better help information for layouts is another thing I'm working on.  It will probably be attached to a command "help-for-layouts", but that's not certain yet.

[Viktor Ransmayr]

Hello Thomas,

I did check out this setting now, found out that the values are almost identical to the 'layout command' names - as well as - I now also understand, why 'legacy' is the default layout ;-)

Thanks a lot for your support !

With kind regards,

Viktor

[Thomas Passin]

On Wednesday, October 16, 2024 at 3:00:08 PM UTC-4 viktor....@gmail.com wrote:

I did check out this setting now, found out that the values are almost identical to the 'layout command' names - as well as - I now also understand, why 'legacy' is the default layout ;-)

Thanks a lot for your support !

Thank you for having the patience to keep testing! Your comments and test results have helped me make the new layout system better.  BTW, what layout have you ended up with as your default layout?

[Viktor Ransmayr]

Hello Thomas,

• @string qt-layout-name = vertical-thirds

An obvious choice ( for my taste ;-)

With kind regards,

Viktor

 

[Thomas Passin]

Mine too.

[Viktor Ransmayr]

Why all these changes (& additions) to the original schedule ?

Sent from my phone !

--
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/73b1dfc0-7931-454d-8b6a-9e8ecdff4522n%40googlegroups.com.

[Edward K. Ream]

On Sat, Oct 26, 2024 at 1:23 PM Viktor Ransmayr <viktor....@gmail.com> wrote:

Why all these changes (& additions) to the original schedule ?

Good question. We had to finish layouts, and the Jupyter support was too good to ignore.

I am confident that Leo 6.8.2 will go out the door November 8.

Edward

[HaveF HaveF]

How often have I wished for a monitor with a greater height than width! 

There are many monitors that can rotate. For example, the one I use now is dell u2422. There should be many models, or you can buy a bracket with rotation.

I like to use the monitor vertically. Many websites now leave too much blank space on both sides, and it is impossible to appreciate this aesthetic.

 

[Edward K. Ream]

On Saturday, October 26, 2024 at 3:10:31 PM UTC-5 Edward K. Ream wrote:

On Sat, Oct 26, 2024 at 1:23 PM Viktor Ransmayr wrote:

Why all these changes (& additions) to the original schedule ?

Good question. We had to finish layouts, and the Jupyter support was too good to ignore.

I am confident that Leo 6.8.2 will go out the door November 8.

Let me assure you and everyone else that Leo 6.8.2 will contain no more substantive changes:

- I expect to merge PR #4119 (@jupytext) today or tomorrow.

- Neither of the two remaining issues is a release blocker.

- All new issues shall be assigned to 6.8.3 or later.

Count on it :-)

Edward

[Edward K. Ream]

On Sunday, October 27, 2024 at 3:06:22 AM UTC-5 Edward K. Ream wrote:

> I am confident that Leo 6.8.2 will go out the door November 8.

Still true. I have just merged PR #4123 into devel.

Work is going well on PR #4138. I have given myself a deadline of Thursday, October 31 to make this PR ready for review. I'll push the PR to Leo 6.8.3 if I don't meet that deadline.

There are no other code issues on the list.

Edward