The nested-splitter project has collapsed in complexity

[Edward K. Ream]

PR #3911 eliminates the free_layout and nested splitter plugins. This work has reached a milestone.

A single method, LeoQtGui.find_widget_by_name, replaces both plugins!

The node g.command('vr') shows the new world order. See the PR. This node adds the VR pane to either the body pane or the secondary splitter, depending on the setting @string initial-split-orientation.

Yes, this new code is longer and more complex. Faux helpers typically make the code look simpler. But the new code is much better. The new code:

- can do anything that Qt can do.
- does not use the cache.
- is platform-independent.
- is a model for @button nodes and plugins.
- is more specific and explicit.

The old code obscured a design choice. Should the VR pane always share the body pane? I think not. When using the horizontal orientation, the VR pane should appear on the left side of the screen. In other words, the secondary splitter should contain the VR pane.

Similar code could insert any Qt widget anywhere, say a QStackedLayout widget. There is nothing special about QSplitters!

Conversion and documentation

How did I know where the body frame was? Leo's new show-qt-widgets command showed me the hierarchy of widgets.

I also studied the way-too-complex code in ns.add_adjacent. I don't expect others to redo my study. Documenting the new world order is essential. A new info item will contain tips and examples.

The VR3 plugin can follow this general pattern. A new setting, say @string vr3-initial-layout, could contain two (or more!) strings that tell g.command('vr3') which layout to use. Nothing could be more straightforward. Notice: VR3 never executes a user script. The setting just selects one of several static alternatives.

Summary

One new method, LeoQtGui.find_widget_by_name, can replace the free_layout and nested_splitter plugins! These plugins are faux helpers. They limit what users can do.

The PR demonstrates how the VR3 plugin could support arbitrarily many layouts. Just add a new setting. Each outline can choose whatever layout it wants!

Documenting the new world order is essential. A new info item will contain tips and examples.

More work is coming. Stay tuned.

All your comments and questions are welcome.

Edward

[Thomas Passin]

This is all looking good.  The command gui.find_widget_by_name is especially valuable.  Without it one has to spend a lot of annoying time fishing around through parent and child widgets to find the one you want.  You also need a way to find the name of the widget you want, which could be hard to find. The new show-qt-widgets  helps a lot here. I think there may be room for another way to show the names, but for now this command does the job.

I already have my script to toggle VR3 over the body editor working with both the new and old layouts.

[Edward K. Ream]

On Mon, May 20, 2024 at 8:08 AM Thomas Passin <tbp1...@gmail.com> wrote:

This is all looking good.  The command gui.find_widget_by_name is especially valuable. 

Glad you like it!

I already have my script to toggle VR3 over the body editor working with both the new and old layouts.

The PR now contains a prototype version of g.command('vr3'). I don't pretend to know if it is what you want. Feel free to suggest any changes to VR3 in the PR. On my machine, strange things happen when I instantiate VR3.  An external program generates a message!

Imo, there is no way to have the free_layout and nested_splitter plugins coexist with the PR. I am considering moving those two plugins to the attic.

Edward

[Thomas Passin]

On Monday, May 20, 2024 at 10:39:14 AM UTC-4 Edward K. Ream wrote:

Imo, there is no way to have the free_layout and nested_splitter plugins coexist with the PR. I am considering moving those two plugins to the attic.

I wouldn't go that far.  My script tries to use the free_layout method to find the right widget to insert VR3 into, and that raises an exception it uses the new method instead.  One could easily move the script into the plugin itself as a command. So I think they could coexist - with some rewriting, of course.

This works when the plugin is not enabled in the settings.  So it never uses the "provider" mechanism and never gets registered with the nested splitter machinery (which doesn't exist in the new approach, of course). 

The question is, then, what will count as a plugin without the provider infrastructure?  We certainly want people to be able to write code and have it work with Leo, and some existing plugins aren't GUI-related and don't use the nested splitter code anyway.  It seems we have to rethink the idea of a GUI plugin and how it should work.

We shouldn't send the plugins to the attic, because people are using them.  Let's find another way.

[Edward K. Ream]

On Mon, May 20, 2024 at 10:20 AM Thomas Passin <tbp1...@gmail.com> wrote:

Imo, there is no way to have the free_layout and nested_splitter plugins coexist with the PR. I am considering moving those two plugins to the attic.

I wouldn't go that far.  My script tries to use the free_layout method to find the right widget to insert VR3 into, and that raises an exception it uses the new method instead.  One could easily move the script into the plugin itself as a command. So I think they could coexist - with some rewriting, of course.

I'm willing to leave the two plugins where they are, untouched.

However, I don't think you (or anyone else) will be able to use them reliably. In the PR, dw.createMainLayout creates the main and secondary splitters as QSplitters, not NestedSplitters. This change is essential. Otherwise the free_layout plugin is privileged, that is, baked into Leo.

But the new widget hierarchy changes all of free_layout's assumptions. Imo, this will likely cause problems with the free_layout plugin.

Summary

I stand by my statement that the PR creates an environment that can not coexist with the two plugins. However, there is no harm leaving the two plugins where they are.

The strategy you propose (moving scripts into the VR3 plugin) will work. I think you'll find that those scripts may as well ignore the free_layout plugin.

Thomas, I'll be happy to zoom with you if you like.

Edward

[Thomas Passin]

On Monday, May 20, 2024 at 5:31:52 PM UTC-4 Edward K. Ream wrote:

On Mon, May 20, 2024 at 10:20 AM Thomas Passin <tbp1...@gmail.com> wrote:

Imo, there is no way to have the free_layout and nested_splitter plugins coexist with the PR. I am considering moving those two plugins to the attic.

I wouldn't go that far.  My script tries to use the free_layout method to find the right widget to insert VR3 into, and that raises an exception it uses the new method instead.  One could easily move the script into the plugin itself as a command. So I think they could coexist - with some rewriting, of course.

I'm willing to leave the two plugins where they are, untouched.

However, I don't think you (or anyone else) will be able to use them reliably. In the PR, dw.createMainLayout creates the main and secondary splitters as QSplitters, not NestedSplitters. This change is essential. Otherwise the free_layout plugin is privileged, that is, baked into Leo.

To the contrary, in my private branch based on the ekr-3910-no-fl-ns-plugins branch, I have got VR3 so it can:

1. For a vr3-open or vr3-toggle command, it opens below the log frame, which is the new behavior you set up;

2. I can toggle it on and off in its own tab in the log frame;

3. My script to put into the body editor's stacked widget and toggle between the body pane and VR3 works.  The script could be added to the VR3 code although I haven't done that yet.

What I don't know yet, with the new layout scheme, is how to open a third pane and put VR3 into that the way it did originally - or moving the log frame (with VR3 in its own tab there) to a third panel.  Having it share vertical height with the log pane is not ideal because you can't see enough of the rendered view.  Having it in a tab in the log frame is better, but the display switches away from VR3 to the log tab whenever there is output to the log.  That's not ideal either, though it's not as bad.

I have been learning that toggling between the body editor and the VR3 rendered view is usually the most useful way to use it.

There is probably a lot of cleanup to be done with all the changes - especially for a different layout.  I don't know how to set a different layout yet so I haven't tested that.

The RPCalc plugin toggles on and off in the log frame with no changes.

Anyway, I'm optimistic about VR3 and similar plugins continuing to work with minimal changes in the new layout regime.

[Edward K. Ream]

On Mon, May 20, 2024 at 10:13 PM Thomas Passin <tbp1...@gmail.com> wrote:

>> However, I [EKR] don't think you (or anyone else) will be able to use [the two plugins] reliably. In the PR, dw.createMainLayout creates the main and secondary splitters as QSplitters, not NestedSplitters.

> To the contrary, in my private branch based on the ekr-3910-no-fl-ns-plugins branch, I have got VR3 so it can: [snip]

I am glad you are happy to work with my changes. Please let me know if I can be of any help.

Is your experimental version of VR3 using the free_layout command?

Are you good with me merging the PR today?

Edward

[Thomas Passin]

On Tuesday, May 21, 2024 at 7:46:15 AM UTC-4 Edward K. Ream wrote:

On Mon, May 20, 2024 at 10:13 PM Thomas Passin <tbp1...@gmail.com> wrote:

Is your experimental version of VR3 using the free_layout command?

Not any more.

 

Are you good with me merging the PR today?

If you mean merging my private branch (PR #3924) with  your ekr-3910-no-fl-ns-plugins branch, please go ahead right away.  The reason is that it contains code to display images with relative URLs correctly when the rendering is exported. I developed that code in a branch that is based off of devel - before the new layout code. My new PR includes both that work and my recent work using the new free-layout free code. If you merge your branch into devel before merging my PR, I will have to do all that work over again, and it was not easy.

If you mean merging with devel,  I'm less sure. Without my changes, I don't think VR3 will be very useful and I believe that there are a few day-to-day users out there.

How about if we take a little survey in this group and ask who is using which GUI plugins?  That might give us some guidance before the change to the new way.

[Edward K. Ream]

On Tue, May 21, 2024 at 8:43 AM Thomas Passin <tbp1...@gmail.com> wrote:

Is your experimental version of VR3 using the free_layout command?

Not any more.

Good.

 

Are you good with me merging the PR today?

If you mean merging my private branch (PR #3924) with  your ekr-3910-no-fl-ns-plugins branch, please go ahead right away. 

Will do.

How about if we take a little survey in this group and ask who is using which GUI plugins?  That might give us some guidance before the change to the new way.

Good idea.

Edward

[Edward K. Ream]

On Tue, May 21, 2024 at 8:43 AM Thomas wrote:

 

Are you good with me merging the PR today?

If you mean merging my private branch (PR #3924) with  your ekr-3910-no-fl-ns-plugins branch, please go ahead right away.  

Done.

Before and after the merge,  the `vr3` command works as I expect, but it also causes a weird interaction with Windows 11. I get a message saying "Press Alt-Z to use GeForce experience"!! I have no idea what is going on.

Thomas, please test the ekr-3910-no-fl-ns-plugins branch and report if you notice anything unusual with the `vr3` command.  Thanks.

Edward

[Thomas Passin]

On Tuesday, May 21, 2024 at 1:10:16 PM UTC-4 Edward K. Ream wrote:

If you mean merging my private branch (PR #3924) with  your ekr-3910-no-fl-ns-plugins branch, please go ahead right away.  

Done.

Before and after the merge,  the `vr3` command works as I expect, but it also causes a weird interaction with Windows 11. I get a message saying "Press Alt-Z to use GeForce experience"!! I have no idea what is going on.

Thomas, please test the ekr-3910-no-fl-ns-plugins branch and report if you notice anything unusual with the `vr3` command.  Thanks.

I'm about to do that very thing.  I don't have Windows 11, only Windows 10, and I will be resisting W11 as long as possible.  So I may not be able to work on that particular quirk. 

[Edward K. Ream]

On Tue, May 21, 2024 at 1:04 PM Thomas Passin wrote:

>> Thomas, please test the ekr-3910-no-fl-ns-plugins branch and report if you notice anything unusual with the `vr3` command.  Thanks.

> I'm about to do that very thing.  I don't have Windows 11, only Windows 10, and I will be resisting W11 as long as possible.  So I may not be able to work on that particular quirk.

Excellent. Every bit of testing helps.

Again, feel free to change my new code in any way you like.

Edward

[Thomas Passin]

VR3 is working with  ekr-3910-no-fl-ns-plugins, possible quirks aside.  Will check soon on Linux.  Freewin is working. RPCalc is still working.

Did you by any chance bind the vr3 command to a key shortcut? W11 might be using that shortcut itself by default.

[Thomas Passin]

On Tuesday, May 21, 2024 at 3:36:03 PM UTC-4 Thomas Passin wrote:

VR3 is working with  ekr-3910-no-fl-ns-plugins, possible quirks aside.  Will check soon on Linux.  Freewin is working. RPCalc is still working.

The new layout in-body does put VR3 in a new panel next to the body editor.  But that whole frame is squashed all the way over to the right so it's not visible.  You have to notice the splitter separator and drag it to pull the body.VR3 frame into visibility.

[Edward K. Ream]

On Tue, May 21, 2024 at 2:36 PM Thomas Passin <tbp1...@gmail.com> wrote:

VR3 is working with  ekr-3910-no-fl-ns-plugins, possible quirks aside.  Will check soon on Linux.  Freewin is working. RPCalc is still working.

Excellent. Thanks for testing.

Did you by any chance bind the vr3 command to a key shortcut? W11 might be using that shortcut itself by default.

No, there is no binding for vr3. I've been executing vr3 from the minibuffer.

Edward

[Edward K. Ream]

On Tue, May 21, 2024 at 3:59 PM Thomas Passin <tbp1...@gmail.com> wrote:

The new layout in-body does put VR3 in a new panel next to the body editor.  But that whole frame is squashed all the way over to the right so it's not visible.  You have to notice the splitter separator and drag it to pull the body.VR3 frame into visibility.

Oops. I forgot to equalize one splitter.  Fixed in rev ff3b04b.

Edward

[Thomas Passin]

On Tuesday, May 21, 2024 at 3:36:03 PM UTC-4 Thomas Passin wrote:

VR3 is working with  ekr-3910-no-fl-ns-plugins, possible quirks aside.  Will check soon on Linux.  Freewin is working. RPCalc is still working.

OK on linux so far. 

[Edward K. Ream]

Thanks for your testing!

Edward