This will be complicated enough and have a potentially big impact on
existing code and users that I'd like to see a concept of operations and
some requirements. For one thing, without something like them no one will
be able to help you. For another, no one will know how things should work
nor how to write code for them. In addition, it's much easier to correct
mistakes early, and if we can have some discussion about the goals and the
design, the community could help.
Saying that you will "invert" Terry's code so the helpers are higher up or
more visible is not very definite or specific. I'd rather start with what
Terry's code does that we like, and what about it we don't like. For
example, I found I can open VR3 on top of the body editor without using a
nested splitter except to use it to find the stacked widget that contains
the body editor. I need free layout instance to get that splitter but not
for anything else. If I could directly get that stacked widget I would not
have to talk to the free layout or a nested splitter at all. So to me, it
would be very desirable to have a method on c to return a container of a
known object, and probably to enumerate those objects and containers,
without having to know how to work my way through all the current layers of
splitters and container widgets. Notionally, something like this:
body_widget = c.getObject('bodyWrapper1')
container = body_widget.parent()
my_widget_index = container.add(myWidget(c))
container.setIndex(my_widget_index)
The log frame works much like this. Why can't all the container frames be
more or less like the Log frame?
There are many Qt applications out there that have multiple panels and
frames. In some of them parts can be torn off and moved elsewhere. New
frames can be opened and populated. I don't suppose they all do it the same
way, but there are probably some standard ways. Pyzo is probably as good
an exemplar as we could find. Just how should the revised Leo interface
work, from the point of view of users? That would be a good place to start.
On Thursday, May 16, 2024 at 7:44:19 PM UTC-4 Edward K. Ream wrote:
> On Thursday, May 16, 2024 at 1:44:43 PM UTC-5 Edward K. Ream wrote:
>
> >> I hope that existing GUI plugins that use the
> nested-splitter/free-layout will be able to continue working without
> needing to be reworked
>
> > When True, the *g.allow_nested_splitter* switch enables both plugins to
> work as before. As noted in the PR, this switch might be on "forever."
>
> Belay that. Leo's codebase should not contain toxic code switches. Such
> switches are intolerable in the long run.
>
> I feel strongly enough about this that I am willing to convert legacy code
> myself. This offer extends to you, Thomas, and anyone else.
>
> *Assuming the PR succeeds,* here is my present plan:
>
> - Terry's plugins (and the switch) will be part of Leo 6.7.9.
>
> - As part of 6.7.9, I'll convert all affected code in LeoPyRef.py.
>
> - The 6.7.9 release notes will warn of a breaking change in Leo 6.7.10 and
> will offer to help with conversion.
>
> - I'll remove the switch and the two plugins as soon as 6.7.9 goes out the
> door.
>
> *Summary*
>
> If PR #3911 <https://github.com/leo-editor/leo-editor/pull/3911> succeeds,
> Leo 6.7.9 will be the last release that supports the free_layout and
> nested_splitter plugins.
>
> The 6.7.9 release notes will warn of the breaking change and will offer
> to help convert any existing code.
>
> Leo's long history includes removing many overly complex features.
> Removing all vestiges of these plugins will make Leo simpler and more
> maintainable.
>
> Again, I welcome all comments.
>
> 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/6e0608b6-1b25-4142-84b8-105b58f9bc8bn%40googlegroups.com.
