ENB: More about layouts

[Edward K. Ream]

Experiments yesterday show that my undoer scheme is a failure. Changing an existing layout is significantly harder than creating a new layout. This Engineering Notebook post will discuss the next steps.

Starting from scratch

The only way forward is to try Jake's idea of deleting the existing layout before creating another. A prototype script will delete the top-level main-splitter widget. That script will leave the test outline in an unusable state, so I'll be using the restart-leo command often.

As a side effect, all of the existing prototype layout scripts must be rewritten.

The VR and VR3 plugins

The fix for #4009 was not to call deleteLater in the onClose functions. This fix applies to both VR and VR3.

My work on the undo-layout code revealed several design flaws in both plugins:

- Both plugins manage the placement (layout) of the VR panes. This makes no sense. The plugins should not be concerned with their widget's place in the gui hierarchy!

- Both plugins create a "controllers" dictionary that maps commanders to vr panes. This dict is unnecessary. These references make it harder to delete the VR panes. Instead, the plugins could inject new "c.vr" or "c.vr3" ivars. The "starting from scratch" process will clear these ivars.

The early prototype scripts will place only the VR3 pane (because the VR3 pane is easier to see). Substantial packaging changes may be required for the VR and VR3 plugins. Early prototypes can safely ignore such details.

Next steps

- Merge PR #4014 into devel to fix #4009.

- Create a new branch to hold changes to the VR and VR3 plugins.

- In the new branch, create prototype scripts to experiment with creating new layouts from scratch.

Packaging

Eventually, the new layout code may migrate into the DynamicWindow class. "c.frame.top" gives access to this class, so the prototypes can easily use the resources in the DynamicWindow class.

Summary

Prototype Leonine scripts will contain initial experiments. All of the existing layout scripts must be rewritten. It will suffice to focus on a single new layout at first.

The VR and VR3 plugins should know nothing about layouts. These plugins probably should not hold references to the VR panes.

The first experiment will delete the contents of the main window! Later experiments will create layouts "starting from scratch". I'll be using restart-leo a lot :-)

Leo's API must remain strictly unchanged. That is, all layouts must define the relevant official ivars.

All questions and comments are welcome.

Edward

[Edward K. Ream]

On Sunday, July 21, 2024 at 6:14:50 AM UTC-5 Edward K. Ream wrote:

> This Engineering Notebook post will discuss the next steps.

I have just opened #4016 for this project. This issue contains a link to Jake's four proposed new layouts.

Edward

[Thomas Passin]

I think there should be a Layout class that contains 

1. A description of a layout;

2. A method that can create the layout from the description.

[Edward K. Ream]

On Sun, Jul 21, 2024 at 7:05 AM Thomas Passin <tbp1...@gmail.com> wrote:

I think there should be a Layout class that contains 

1. A description of a layout;

2. A method that can create the layout from the description.

I agree. A Layout class would be part of what I described as "packaging". It will happen in some form.

Edward