One thing to resolve is where these kinds of layout scripts should be stored and managed. It's one thing for me to have a private collection of scripts and commands, but another to make them usable and available to other Leo users, and yet another to make it easy to add new ones.
I don't favor making them part of core Leo code. Here are some alternatives: 1. The layout commands are supplied by one or more plugins in some fashion. This might make it harder to provide custom menus, since if I understand things, settings-defined menus are created before any plugin runs; 2. The layout commands are contained in a folder, whether "plugins" or a new "layouts" folder. The core code ingests these commands at some point where they can be used by settings to make custom menus. 3. The commands are contained in a folder and a script writer can import commands fromt that folder; 4. The commands are located in @command settings nodes in LeoSettings.leo, which also would contain definitions for a new "Layout" menu. As with other commands, a user could add other settings commands to myLeoSettings and make custom menus with them all. I favor # 4. My own layout scripts all reside in myLeoSettings.leo and it works very well. It's easy to change them. Changes to the scripts in LeoSettings.leo could be committed without touching code Leo code and LeoPyRef, which seems like a good thing. On Saturday, August 31, 2024 at 9:05:39 AM UTC-4 Edward K. Ream wrote: > On Sat, Aug 31, 2024 at 6:56 AM Thomas Passin wrote: > > 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. >> > > Excellent. We can deal with event handlers later, if need be. > > 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. >> > > Alright. Again, we can deal with the complications later. > > 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. >> > > I agree. > > Long run: >> >> Create a core Widget, inheriting from QWidget, that has known methods for >> finding, hiding, deleting, and reusing itself. >> > > I prefer not to create subclasses of gui objects unless necessary, so I > would prefer these be DynamicWindow methods, but let's defer this > discussion. > > I would be happy to take the lead in this work if you would like that. >> > > Thanks. Having you do the work is the fastest way forward for you. The > more general approach (getting reload-outline to work properly without > *ever* calling restart-leo) might be ideal, but we both know that way > isn't as easy as it appears. > > 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/ef414f55-6044-48c3-89de-013345806579n%40googlegroups.com.
