New Layout System Getting Close

[Thomas Passin]

I have been improving the new layout and integrating it into Leo's code base. For those of you who so kindly tried out the demo scripts earlier, here's what has changed:

1. A new python file, leo/plugins/qt_layout.py.  This contains some layout descriptors, and a new LayoutCacheWidget Qwidget.  This widget serves as a place to store layout components not needed by the current layout, so they can be found when needed again.  It also has code to apply layouts using a layout descriptor.  All six of Leo's current standard layouts are reproduced in the qt_layout module, most of them using layout descriptors.

2. The DynamicWindow of an outline now creates a instance of the LayoutCacheWidget during startup.  This is always available as:

    dw = c.frame.top
  cache = dw.layout_cache

Given a layout descriptor, applying it is simple:

    cache.restoreFromLayout(layout)

The programming techniques some people used to create other layouts will still work, but they should be changed to store unused splitters and widgets in the new cache widget.

Some VR3 commands have been adjusted to play better with the new code, especially vr3-toggle and vr3-show.

A PR for the new code has been submitted.  You don't have to wait for it to be reviewed and merged - get the tbp-leo_layouts branch from my cloned repo at

https://github.com/tbpassin/leo-editor/tree/tbp-leo_layouts

I have also revised the Layout-Demo outline.  It creates a new menu filled with items that show how many of the commands work, along with others that are scripts not included in the qt_layout module.  This outline can be gotten from my repo at

https://github.com/tbpassin/leo-editor-contrib/tree/devel/Projects/new-layout

Be sure to read the "About This Outline" node in the outline.

[Viktor Ransmayr]

Hello Thomas,

tbp1...@gmail.com schrieb am Dienstag, 1. Oktober 2024 um 19:26:44 UTC+2:

I have been improving the new layout and integrating it into Leo's code base. For those of you who so kindly tried out the demo scripts earlier, here's what has changed:

...

A PR for the new code has been submitted.  You don't have to wait for it to be reviewed and merged - get the tbp-leo_layouts branch from my cloned repo at

https://github.com/tbpassin/leo-editor/tree/tbp-leo_layouts

I have also revised the Layout-Demo outline.  It creates a new menu filled with items that show how many of the commands work, along with others that are scripts not included in the qt_layout module.  This outline can be gotten from my repo at

https://github.com/tbpassin/leo-editor-contrib/tree/devel/Projects/new-layout

Be sure to read the "About This Outline" node in the outline.

I've done a short test of your new layout system integrated into Leo's code base.

It does not work in my Fedora Linux 40 environment, although I believe I followed all documented steps ...

Here are my logs from this test:

* Check if repo 'tbp-leo_layouts' is up to date - OK - See "Log-001".
* Close & re-open this outline using the Leo variant from Thomas - OK - See "Log-002".
* Open the outline 'Layout-Demo' & try LD > Leo's "Legacy" Layout - Not OK - See "Log-003".
* Try LD > Restore Default Layout From Settings - Not OK - See "Log-004".

Let me know if you need further info from my environment.

With kind regards,

Viktor

 

### Log-001

    [user@fedora-leo-study-vm ~]$
    [user@fedora-leo-study-vm ~]$ cd PyVE/GitHub/tbpassin/Leo
    [user@fedora-leo-study-vm Leo]$
    [user@fedora-leo-study-vm Leo]$ cd leo-editor/
    [user@fedora-leo-study-vm leo-editor]$
    [user@fedora-leo-study-vm leo-editor]$ git branch
      master
    * tbp-leo_layouts
    [user@fedora-leo-study-vm leo-editor]$
    [user@fedora-leo-study-vm leo-editor]$ git pull
    remote: Enumerating objects: 5, done.
    remote: Counting objects: 100% (5/5), done.
    remote: Total 5 (delta 4), reused 5 (delta 4), pack-reused 0 (from 0)
    Unpacking objects: 100% (5/5), 911 bytes | 82.00 KiB/s, done.
    From https://github.com/tbpassin/leo-editor
       20bcef808..532f9467f  tbp-leo_layouts -> origin/tbp-leo_layouts
    Updating 20bcef808..532f9467f
    Fast-forward
     leo/plugins/qt_layout.py | 37 +++++++++++++++++++++++++++++++++++++
     1 file changed, 37 insertions(+)
    [user@fedora-leo-study-vm leo-editor]$

### Log-002

    Leo Log Window
    Leo 6.8.2-devel, tbp-leo_layouts branch, build 532f9467fa
    2024-10-05 16:43:51 -0400
    Python 3.12.6, PyQt version 6.6.3
    linux
    setting leoID from os.getenv('USER'): 'user'
          home: /home/user
    leo-editor: /home/user/PyVE/GitHub/tbpassin/Leo/leo-editor
          load: /home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/core
        config: /home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/config
    reading settings in /home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/config/leoSettings.leo
    reading settings in /home/user/.leo/myLeoSettings.leo
    reading settings in /home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/themes/tbp_dark_solarized.leo
    VR3 -- no asciidoc processor
    VR3 -- no asciidoc3 processor
    Can't find /home/user/.leo/vr3/vr3_config.ini so VR3 cannot execute non-Python code
    reading settings in /home/user/Documents/SL2024.leo
    read outline in 0.24 seconds

### Log-003

    Leo Log Window
    Leo 6.8.2-devel, tbp-leo_layouts branch, build 532f9467fa
    2024-10-05 16:43:51 -0400
    Python 3.12.6, PyQt version 6.6.3
    linux
    reading settings in /home/user/Projects/GitHub/tbpassin/leo-editor-contrib/Projects/new-layout/Layout-Demo.leo
    read outline in 0.00 seconds
    Traceback (most recent call last):
      File "/home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/core/leoCommands.py", line 2760, in doCommand
        return_value = command_func(event)
                       ^^^^^^^^^^^^^^^^^^^
      File "/home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/plugins/qt_layout.py", line 104, in layout_legacy
        cache.restoreFromLayout(LEGACY_LAYOUT)
      File "/home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/plugins/qt_layout.py", line 550, in restoreFromLayout
        widget = self.created_splitter_dict[name]
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
    KeyError: 'viewrendered_pane'

### Log-004

    Traceback (most recent call last):
      File "/home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/core/leoCommands.py", line 2760, in doCommand
        return_value = command_func(event)
                       ^^^^^^^^^^^^^^^^^^^
      File "/home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/plugins/qt_layout.py", line 75, in restoreDefaultLayout
        c.commandsDict[layout](event)
      File "/home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/plugins/qt_layout.py", line 104, in layout_legacy
        cache.restoreFromLayout(LEGACY_LAYOUT)
      File "/home/user/PyVE/GitHub/tbpassin/Leo/leo-editor/leo/plugins/qt_layout.py", line 550, in restoreFromLayout
        widget = self.created_splitter_dict[name]
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
    KeyError: 'viewrendered_pane'

[Thomas Passin]

Than you for testing.  It looks like you do not have the viewendered.py plugin enabled.  Would you mind enabling it (as well as viewrendered3.py) and trying again?  I will look at the code and work out the best way to handle the cases where either VR or VR3 are not enabled. I have been under the impression that VR was always present whether formally enabled or not.

I'm not sure that simply changing from widget = self.created_splitter_dict[name] to widget = self.created_splitter_dict.get(name) will be enough because other parts of the code might need some adjustment too.

If you already have VR enabled then I'm temporarily stumped.

[Viktor Ransmayr]

Hello Thomas,

tbp1...@gmail.com schrieb am Sonntag, 6. Oktober 2024 um 22:51:45 UTC+2:

Than you for testing.  It looks like you do not have the viewendered.py plugin enabled.

Correct - but - as you can see in "Log-002" viewrendered3.py is enabled ! - I never enable VR & VR3 at the same time ...

 

Would you mind enabling it (as well as viewrendered3.py) and trying again?  I will look at the code and work out the best way to handle the cases where either VR or VR3 are not enabled. I have been under the impression that VR was always present whether formally enabled or not.

I'm not sure that simply changing from widget = self.created_splitter_dict[name] to widget = self.created_splitter_dict.get(name) will be enough because other parts of the code might need some adjustment too.

If you already have VR enabled then I'm temporarily stumped.

Just for the record, here's the output from "Leo > Plugins > show-plugins-info":

leo.plugins.plugins_menu  myLeoSettings.leo
leo.plugins.mod_scripting myLeoSettings.leo
leo.plugins.viewrendered3 myLeoSettings.leo
leo.plugins.freewin       myLeoSettings.leo
leo.plugins.rpcalc        myLeoSettings.leo

With kind regards,

Viktor

[Thomas Passin]

On Sunday, October 6, 2024 at 5:17:22 PM UTC-4 viktor....@gmail.com wrote:

Hello Thomas,

tbp1...@gmail.com schrieb am Sonntag, 6. Oktober 2024 um 22:51:45 UTC+2:

Than you for testing.  It looks like you do not have the viewendered.py plugin enabled.

Correct - but - as you can see in "Log-002" viewrendered3.py is enabled ! - I never enable VR & VR3 at the same time ...

I do usually enable them both at the same time.  I don't recall if I have ever tested any code with only one enabled. It looks like I will have to start doing that.

 

[Viktor Ransmayr]

Hello Thomas,

First the good news: After I enabled 'viewrendered.py' plugin in addition this morning, the tracebacks are gone !

Since I did all my tests of your initial script-based layout demo ONLY with 'viewrendered3.py' successfully, I assumed that enabling only VR3 SHOULD be sufficient ...

I'll continue my tests & will report any issues I'll encounter.

With kind regards,

Viktor

[Thomas Passin]

Viktor, I've got all these cases of the missing VR/VR3 taken care of but before I push the changes up where you can try them, I'd appreciate your thoughts on a few things.

First, I have followed the way that the current system creates layouts that include VR or VR3.  They set up a place for it but don't actually put VR/VR3 into it and show the widget unless it's already open and shown. It seems to me that if one asks for a layout that includes VR/VR3 that they would expect VR/VR3 will immediately be visible in that layout.  What do you think?

Second, I have some layouts that use VR and some that use VR3.  I think that these layouts should (like, for example, "Big Tree") should open with VR3 if available otherwise with VR.  That will be a little tricky to arrange but I think it can be done.  Do you have an opinion here?

The third thing I would welcome your opinion on is about which layouts should be included in the core code vs which ones could be defined in @settings tree.  The Layout-Demo outline uses a mix of both. My thinking is that some layouts may only be useful to a few users (like me or you!) whereas others would see more widespread use. Of course new layouts can be created by anyone - if they can do the small amount of scripting - and put into an @settings tree. I'm unsure where to draw the line between core commands and non-core ones.  What is your opinion?

Implementing any of these thoughts will take me some little time and need some testing as well.

Thanks!

[Viktor Ransmayr]

Hello Thomas,

Am Di., 8. Okt. 2024 um 01:55 Uhr schrieb Thomas Passin <tbp1...@gmail.com>:

Viktor, I've got all these cases of the missing VR/VR3 taken care of but before I push the changes up where you can try them, I'd appreciate your thoughts on a few things.

I'm on the road today !

I'll try to spend some time tonight & will provide my feedback / opinion on those issues tomorrow.

With kind regards,

Viktor

[Viktor Ransmayr]

Hello Thomas,

tbp1...@gmail.com schrieb am Dienstag, 8. Oktober 2024 um 01:55:20 UTC+2:

Viktor, I've got all these cases of the missing VR/VR3 taken care of but before I push the changes up where you can try them, I'd appreciate your thoughts on a few things.

• I assume this means that VR & VR3 do NOT have to be enabled at the same time in the future. - Correct ?

First, I have followed the way that the current system creates layouts that include VR or VR3.  They set up a place for it but don't actually put VR/VR3 into it and show the widget unless it's already open and shown. It seems to me that if one asks for a layout that includes VR/VR3 that they would expect VR/VR3 will immediately be visible in that layout.  What do you think?

• Should VR/VR3 'content' be immediately visible - or - should the user explicitly request it ?
• For me this is not an OR - but - an AND ! - I believe there are situations (e.g. single screen / small laptop, etc.) where the user should be able to toggle to save 'screen estate'.

 

Second, I have some layouts that use VR and some that use VR3.  I think that these layouts should (like, for example, "Big Tree") should open with VR3 if available otherwise with VR.  That will be a little tricky to arrange but I think it can be done.  Do you have an opinion here?

• If VR3 is enabled, should it be prioritized over VR ?
• I don't have a strong opinion on this issue - but - somehow it feels 'strange' to me to put plugin - dependencies / relationships into Leo's core code.

 

The third thing I would welcome your opinion on is about which layouts should be included in the core code vs which ones could be defined in @settings tree.  The Layout-Demo outline uses a mix of both. My thinking is that some layouts may only be useful to a few users (like me or you!) whereas others would see more widespread use. Of course new layouts can be created by anyone - if they can do the small amount of scripting - and put into an @settings tree. I'm unsure where to draw the line between core commands and non-core ones.  What is your opinion?

• Which ~ layouts ~ should be offered / provided by Leo's core ?
• I tried out all layouts currently offered by Leo's core. - See "Log-001" below
  
• IMO 'layout-big-tree' & 'layout-vertical-thirds2' are quite special - and - could be just documented as examples.

With kind regards,

Viktor

### Log-001

List available 'layout' cmds in Leo's core.

* Try 'layout-legacy' - OK - 4 tiles.
* Try 'layout-restore-default' - OK? - No change ...
* Try 'layout-fallback-layout' - OK - Back to own start settings.
* Try 'layout-swap-log-panel' - OK - 3 tiles.
* Try 'layout-swap-log-panel' - OK - Back to own start settings.
* Try 'layout-vertical-thirds' - OK - 3 tiles.
* Try 'layout-big-tree' - OK - Special 4 tiles.
* Try 'layout-fallback-layout' - OK - Back to own start settings.
* Try 'layout-vertical-thirds2' - OK - Special 4 tiles.
* Try 'layout-fallback-layout' - OK - Back to own start settings.

[Edward K. Ream]

On Wed, Oct 9, 2024 at 6:13 AM Viktor Ransmayr wrote:

Here are some comments for both Viktor and Thomas:

> I assume this means that VR & VR3 do NOT have to be enabled at the same time in the future. - Correct ?

Correct. My testing (in "devel") indicates that layouts show only one of VR or VR3.

> Should VR/VR3 'content' be immediately visible - or - should the user explicitly request it ?

Leo (all layouts, afaik) shows VR/VR3 panes only after the user requests them.

> it feels 'strange' to me to put plugin - dependencies / relationships into Leo's core code.

The VR/VR3 panes are integral parts of every layout. The recent layout work supports layouts in Leo's core, so the dependencies are expected. Thomas's code handles these dependencies cleanly.

> Which ~ layouts ~ should be offered / provided by Leo's core ?

All of them. Plugins can create new layouts fairly easily, but afaik nobody has tested that capability.

Summary of my testing

I haven't been able to have both VR and VR3 panes open simultaneously. This looks like a bug, but imo the "devel" branch is good enough to release as it is. Perhaps only Thomas wants to switch between VR and VR3 while switching layouts. If necessary, he can submit a small PR to remedy any remaining glitches.

Edward

[Thomas Passin]

On Wednesday, October 9, 2024 at 8:21:20 AM UTC-4 Edward K. Ream wrote:

On Wed, Oct 9, 2024 at 6:13 AM Viktor Ransmayr wrote:

> it feels 'strange' to me to put plugin - dependencies / relationships into Leo's core code.

The VR/VR3 panes are integral parts of every layout. The recent layout work supports layouts in Leo's core, so the dependencies are expected. Thomas's code handles these dependencies cleanly.

There is a precedent - F11 and other other "help-for" commands display using VR3 if enabled otherwise VR.

 

> Which ~ layouts ~ should be offered / provided by Leo's core ?

All of them. Plugins can create new layouts fairly easily, but afaik nobody has tested that capability.

Summary of my testing

I haven't been able to have both VR and VR3 panes open simultaneously. This looks like a bug, but imo the "devel" branch is good enough to release as it is. Perhaps only Thomas wants to switch between VR and VR3 while switching layouts. If necessary, he can submit a small PR to remedy any remaining glitches.

It may indeed only be me.  I usually have both enabled, usually for testing, or comparison if I suspect that VR3 isn't acting quite right.

The issue about which to use on layouts is that it would be awkward and maybe confusing, to have, e.g., two "big-tree" layouts, one for VR and one for VR3.

[Edward K. Ream]

On Wed, Oct 9, 2024 at 8:11 AM Thomas Passin

>> EKR: I haven't been able to have both VR and VR3 panes open simultaneously. This looks like a bug, but imo the "devel" branch is good enough to release as it is.

> I usually have both enabled, usually for testing, or comparison if I suspect that VR3 isn't acting quite right.

Good to know.

Edward

[Thomas Passin]

On Wednesday, October 9, 2024 at 9:42:49 AM UTC-4 Edward K. Ream wrote:

On Wed, Oct 9, 2024 at 8:11 AM Thomas Passin

>> EKR: I haven't been able to have both VR and VR3 panes open simultaneously. This looks like a bug, but imo the "devel" branch is good enough to release as it is.

I have them both enabled and visible right now.  It's never been a problem.  When an outline opens, it doesn't have a VR3 instance, whereas it does get a VR instance.  With the current code, the "vr3" command creates an instance but doesn't show it. "vr3-show" or "vr3-toggle" are needed to actually see the instance.  Each of them will create an instance of VR3, even if it's not been enabled in myLeoSettings.leo.  Currently, "vr3-toggle" looks to see if it already has a slot in the layout and it will become visible there if so.  Otherwise, it will get added to the main splitter.

I bind "vr3-toggle" to Alt-0 and "vr-toggle" to Alt-F10. I find this to be easy and convenient.

The reason I don't automatically create a VR3 instance when an outline opens is that instantiating a VR3 object seriously messes up the display.  You've probably noticed a big flash and the Leo window may even distort or move for a second.  These effects are even worse on Linux. It seems to be something to do with Qt creating a Chrome instance and then packaging it into a Qt widget. Chrome is so big and complicated that it takes some little while. None of the usual Qt tricks for suppressing redraws have helped - I suppose it's outside Qt's control.  I think these effects could be unnerving for a user, so I don't like to force them to occur when any outline gets opened, even if the user will never use VR3 with that outline.

[Edward K. Ream]

On Wed, Oct 9, 2024 at 9:59 AM Thomas Passin <tbp1...@gmail.com> wrote:

>> EKR: I haven't been able to have both VR and VR3 panes open simultaneously. This looks like a bug, but imo the "devel" branch is good enough to release as it is.

> I have them both enabled and visible right now.  It's never been a problem.

Hurray. Using vr3 and vr3 toggle works for me. Thanks for your help!

Edward

[Thomas Passin]

On Wednesday, October 9, 2024 at 7:13:18 AM UTC-4 viktor....@gmail.com wrote:

tbp1...@gmail.com schrieb am Dienstag, 8. Oktober 2024 um 01:55:20 UTC+2:

Viktor, I've got all these cases of the missing VR/VR3 taken care of but before I push the changes up where you can try them, I'd appreciate your thoughts on a few things.

• I assume this means that VR & VR3 do NOT have to be enabled at the same time in the future. - Correct ?

Yes, that's right.  Either one or both can be enabled.

 

First, I have followed the way that the current system creates layouts that include VR or VR3.  They set up a place for it but don't actually put VR/VR3 into it and show the widget unless it's already open and shown. It seems to me that if one asks for a layout that includes VR/VR3 that they would expect VR/VR3 will immediately be visible in that layout.  What do you think?

• Should VR/VR3 'content' be immediately visible - or - should the user explicitly request it ?
• For me this is not an OR - but - an AND ! - I believe there are situations (e.g. single screen / small laptop, etc.) where the user should be able to toggle to save 'screen estate'.

Yes, that's how I work.  The commands "vr-toggle" and "vr3-toggle" switch them in and out of visibility.

 

Second, I have some layouts that use VR and some that use VR3.  I think that these layouts should (like, for example, "Big Tree") should open with VR3 if available otherwise with VR.  That will be a little tricky to arrange but I think it can be done.  Do you have an opinion here?

• If VR3 is enabled, should it be prioritized over VR ?
• I don't have a strong opinion on this issue - but - somehow it feels 'strange' to me to put plugin - dependencies / relationships into Leo's core code.

This dependency is already in the core - F11 and some of the other "help-for" commands use VR3 for display if enabled, otherwise they use VR. I am concerned that having a "VR version and a "VR3" version of each layout would be confusing and cause cluttered menus.  This is not a technical programming matter, of course. I have devised a small code change that can optionally (that is, a layout writer can choose to use the feature or not) use VR3 if enabled, VR otherwise. I've proposed a PR to add this feature, and we can see if it causes anyone problems.

 

The third thing I would welcome your opinion on is about which layouts should be included in the core code vs which ones could be defined in @settings tree.  The Layout-Demo outline uses a mix of both. My thinking is that some layouts may only be useful to a few users (like me or you!) whereas others would see more widespread use. Of course new layouts can be created by anyone - if they can do the small amount of scripting - and put into an @settings tree. I'm unsure where to draw the line between core commands and non-core ones.  What is your opinion?

• Which ~ layouts ~ should be offered / provided by Leo's core ?
• I tried out all layouts currently offered by Leo's core. - See "Log-001" below
  
• IMO 'layout-big-tree' & 'layout-vertical-thirds2' are quite special - and - could be just documented as examples.

I included all the layouts the Edward had already built in ... although it's hard for me to see how to use some of them as a practical matter.  I also included the layout I prefer to start out with, as well as one to swap the log frame between the main and secondary splitters.  If anyone can come up with any others, it's easy enough to create them.  New ones can be added to one's myLeoSettings.leo file without needing to change Leo's core code at all.

Edward added code so that the plugin controller can know about the new module.  I didn't realize it but this automatically causes the plugins menu to include a menu with all the new layout commands. I had thought we could add such a menu to LeoSettings.leo but this won't be necessary now. You can still use the Layout-Demo outline but it's not necessary any more.

 

With kind regards,

Viktor

Thank you so much for your testing and suggestions!