Short answer: yes, with a few quirks in the case of added widgets (ones that are not VR/VR3 and RPCalc). These widgets may become lost but still retain their resources and their event hooks.
Long answer: My scripts can be adapted and will work as long as no other other widgets are added besides VR/VR3 and RPCalc. Other widgets would be unknown to the code and applying a new layout would work but undoing it wouldn't work completely because the code would not know they are there. A reload would fix that, of course. My script to restore a default layout examines the main and secondary splitters and removes any splitters that were added. That works but if one of these added splitters contain an unknown widget (again, one of VR/VR3/RPCalc) its removal might lead to some dangling python objects. This is the same problem of deleting any PyQt widget: just running deleteLater removes the C++ parts but not necessarily the Python ones. The script could be modified to also remove added layouts and other widgets. These unknown widgets could be hidden and inactivated - that's how I deal with VR/VR3 when they aren't wanted. There needs to be a way to find them if they will be wanted for reuse in a different layout. Even if we wanted to delete them and not worry about their leaked Python parts, for an arbitrary widget we wouldn't know how to disconnect them from Leo's event hooks. So it would be better to leave hidden hidden and de-parented rather than to destroy them. My opinion is that this is an acceptable compromise. Only script writers will know how to add other widgets. If they know that they can also figure out how to remove them or keep them around but hidden for reuse in another layout. Of course we would write some guidance for them. Long run: Create a core Widget, inheriting from QWidget, that has known methods for finding, hiding, deleting, and reusing itself. All new plugin GUI widgets should inherit from this ancestor. Also create core methods for dealing with these objects when creating and removing a layout. We would convert VR/VR3/RPCalc to inherit from this ancestor instead of from QWidget. In the case of VR/VR3 we have (or used to have) the controllers[h] way to find them and impose the singleton condition. That has worked well for me and might be part of this future work. I would be happy to take the lead in this work if you would like that. On Saturday, August 31, 2024 at 7:05:01 AM UTC-4 Edward K. Ream wrote: > On Fri, Aug 30, 2024 at 11:27 PM Thomas Passin <[email protected]> wrote: > >> Hmm, I've tinkered it down to this and it's just been working on my >> system: > > > Thanks for your experiments. > > Bear in mind that this code doesn't add or change the layout setting. This >> command would be executed after the layout setting had been updated. This >> code just demonstrates how to do the reload part of the task. You could >> edit the layout setting by hand before reloading to demonstrate that it >> works. >> > > Alright. > > Let's consider a separate, parallel, approach. Before the new layout code > became part of Leo, you used scripts to switch between layouts, correct? As > a prototype, could you revise those scripts to work with the new layout > code? Perhaps there is a way to reparent and repopulate the main and > secondary splitters. > > Does this approach seem feasible? If the prototype works we could add > official helper functions to Leo. > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/8b47e8c3-67e1-41fc-a843-105702484bdan%40googlegroups.com.
