It's not necessary that VR/VR3 be in their own separate splitter. None of
my layout scripts create one. In one case, VRx goes into the body frame's
existing tabbed layout widget. In another, it goes into the body frame's
existing splitter. In another it goes into the Log frame. So don't go
making assumptions about added splitters. We have to remember too that
users may write layout scripts for other widgets too. Another wrinkle is
that after running a layout restore script we want to be able to apply
another layout script and have it work. I have learned that isn't always
the case.
Also, don't assume that a script will create a new layout only by inserting
an enabled plugin widget. My VRx layout scripts work fine whether or not
their plugin has been enabled.
Here are some of the things that need to be done to restore the default
layout (I will assume that a only a single Gui widget has been added),
possibly with a new splitter that may have had some standard Leo elements
moved into it. I will call the basic Leo structural widgets (main
splitter, secondary splitter, body frame, log frame, tree) the "standard
widget set" (SWS):
1. Discover the newly added widget. In general we don't know its name.
2. Discover what GUI element it's in and whether or not that element is
part of the SWS.
3. Delete the new widget. Note that none of our usual additional widgets
(VR/VRx and whatever else someone may want to work with in the future) have
a teardown method, let alone a standard API call for it. The teardown has
to:
a. remove any registered hooks into the Leo event system;
b. remove any references the widget has set up outside of itself, such
as *controllers[h]* in the case of VRx;
c. set the widget's parent to None (after making itself invisible,
otherwise it would appear in a free-floating window);
d. delete the widget itself;
4. Reparent any standard SWS widgets back to the standard parents;
5. Reset the orientations of the standard containers to their default
values;
6. Remove any added splitters while NOT removing any of the SWS;
The script I presented above does all these things except it only looks for
VRx, and it knows how to tear them down using insider knowledge.
Restarting Leo to change a layout is just not a viable approach. It's too
slow and disruptive to a user (or at least to me). Yet I don't see a
perfectly general way to restore a standard layout either.
There is a way forward if we are willing to insist on some conventions:
1. Each custom GUI widget, like VR/VR3, must have a teardown API method
with a standard name, such as *teardown()*.
2. The object names of the custom widgets must be recorded somewhere in a
record of the new layout.
3. The object names of any other added GUI components, such as splitters,
must also be recorded.
Developing a *teardown()* method may require some development or even
refactoring for some plugins. But they should have had one all along
anyway.
The conventions would apply to the custom GUI widgets, and writers of
layout scripts would have to make their scripts align with them. There
could, for example, be a new Leo method c.registerLayout(*)**, *and a
layout script would have to call it to make sure that their layout could be
reverted back to the default ( we can assume that the reversion command
will always look for VR/VR3, so layout scripts relocating them could be an
exception).
In the future, no new plugins would be accepted into Leo's plugins
directory unless it complied with these conventions. Anyone who cared could
revise existing plugins. Script writers of layout scripts could always
roll their own and create restore scripts of their own. They just wouldn't
be general.
On Sunday, July 28, 2024 at 4:21:09 AM UTC-4 Edward K. Ream wrote:
> On Sun, Jul 28, 2024 at 3:12 AM Edward K. Ream wrote:
>
> > ...the PR will soon define an *empty layout*. This layout should help
> define @button nodes that define prototype layouts.
>
> Well, that idea quickly blew up. There are a *lot* of assumptions that
> an empty layout would violate.
>
> Edward
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/3dfaca99-d85f-4167-8d9f-c7d98d069a9fn%40googlegroups.com.
