On New-style Layouts And Their Scripts

[Thomas Passin]

We've been discussing how to create new layouts for Leo now that the old nested-splitter system is gone - see https://groups.google.com/g/leo-editor/c/nLfhTgnPcEc

That thread includes a number of interesting scripts that can create new layouts.  But they all have a serious problem: they all assume they are starting from Leo's default layout and they have no way of knowing if the actual layout has been changed before the script is run. If it has, the resulting layout will not be what was intended.

Since essential frames like the tree or body editor may have been switched from the main to the secondary splitter, or even moved to a newly-created splitter, scripts like these need to be able to discover and account for situations like these.

[Edward K. Ream]

On Fri, Jul 19, 2024 at 6:10 AM Thomas Passin <tbp1...@gmail.com> wrote:

We've been discussing how to create new layouts for Leo now that the old nested-splitter system is gone - see https://groups.google.com/g/leo-editor/c/nLfhTgnPcEc

That thread includes a number of interesting scripts that can create new layouts.  But they all have a serious problem: they all assume they are starting from Leo's default layout and they have no way of knowing if the actual layout has been changed before the script is run. If it has, the resulting layout will not be what was intended.

Yes, this is a potential problem, but it will only be a problem if a user dynamically switches between layouts with `@button` or `@command` nodes. Plugins that change layouts probably don't have to worry about unexpected layouts.

Anyway, scripts can test the parents of various widgets to see if those parents are as expected. If not, the script could restore the layout to a known starting point before changing the layout.

In short, a bit more work is needed.

Edward

[Edward K. Ream]

On Fri, Jul 19, 2024 at 6:21 AM Edward K. Ream <edre...@gmail.com> wrote:

> But [all the layout scripts] have a serious problem: they all assume they are starting from Leo's default layout.

Aha. Changing layouts should be undoable!  We can do that :-)

Edward

[Thomas Passin]

"Plugins that change layouts probably don't have to worry about unexpected layouts."

I don't see it.  Many users will want to change from one layout to another.  If a plugin forces a specific layout at startup time, well and good but a user needs to be able to change it.

[Edward K. Ream]

On Fri, Jul 19, 2024 at 6:42 AM Thomas Passin <tbp1...@gmail.com> wrote:

"Plugins that change layouts probably don't have to worry about unexpected layouts."

I don't see it.  Many users will want to change from one layout to another.  If a plugin forces a specific layout at startup time, well and good but a user needs to be able to change it.

Right. So only `@button` or `@command` scripts need to worry about unexpected layouts.

Edward

[Thomas Passin]

I pictured a layout plugin doing it work by running one of those scripts...

[Edward K. Ream]

On Fri, Jul 19, 2024 at 7:32 AM Thomas Passin <tbp1...@gmail.com> wrote:

I pictured a layout plugin doing it work by running one of those scripts...

The big picture is coming into focus:

1. Besides the original helper, g.app.gui.find_widget_by_name, we'll want g.app.gui.restore_layout. This helper will use the "split direction" setting. It should be straightforward to create this helper.

2. We'll probably want four new Qt gui commands to change layouts. There may be no need for plugins or `@button` scripts!

And that's it.

Edward

[Thomas Passin]

"1. Besides the original helper, g.app.gui.find_widget_by_name, we'll want g.app.gui.restore_layout. This helper will use the "split direction" setting. It should be straightforward to create this helper."

I'm not so sure it will be straightforward.  That's because a given layout might have created new splitters and new widgets to go into them.  They will need to be discovered and deleted, which destruction could be object-specific. I'm not saying it can't be done, just that it doesn't seem so straightforward to me.

One possibility could be that layouts will be created using dedicated method calls that would keep a record of new widgets involved with a layout and their locations.  I suppose that this record should use weak references so that an object would actually be deleted by a delete operation and not accidentally kept as a zombie because a reference in the layout record didn't get removed.

I think that an undo sequence as the reverse of the creation sequence ought to be practical.  For example, the creation of a layout:

1. move log frame from secondary to main splitter;

2. move body editor frame from main to secondary;

3. move log frame from main to secondary;

4. create new splitter in main splitter;

5. create new myPluginWidget;

6. insert myPluginWidget into the new splitter.

Moving from 6 to 1 using the inverse operations ought to undo the new layout:

6. remove myPluginWidget from the new splitter;

5. delete  myPluginWidget;

4. delete the new splitter;

3. move log frame from secondary to main;

2. move body editor frame from secondary to main;

1. move log frame from main to secondary.

I haven't thought too hard about it but I hope all these operations will turn out to be commutative.  Otherwise things will be trickier.

[Edward K. Ream]

On Fri, Jul 19, 2024 at 9:04 AM Thomas Passin <tbp1...@gmail.com> wrote:

"1. Besides the original helper, g.app.gui.find_widget_by_name, we'll want g.app.gui.restore_layout. This helper will use the "split direction" setting. It should be straightforward to create this helper."

I'm not so sure it will be straightforward. 

We'll see. I have some ideas.

Edward