I think the old framework had a lot of virtues. But I found it awfully hard to work with, either as a user or when writing scripts. I thought that maybe we could come up with some interface improvements to make it easier to work with, but it ended getting yanked out instead.
I've come up with a layout descriptor that is reminiscent of the old layout descriptors but much less cryptic. The problem is, for custom objects like plugin widgets how to get the code that builds the layout from the descriptor and how to get it to remove an added widget when it's time to change the layout. I think that could be handled by a combination of a registration system and some conventions. I haven't thought very much about how that might work. A registration system might not even be needed. What's needed is to know the object names that have been added and how to instantiate and delete them. If we have that in place, the code to replace a layout with another one isn't very complicated. I've already got a working prototype. As long as the only added widgets are VR/VR3, it can change the layout to another one that doesn't have them. On Tuesday, July 30, 2024 at 5:21:03 PM UTC-4 gates...@gmail.com wrote: > I’m loath to suggest it due to Edward’s apparent dislike of the old > regime, but the old free-layout plugin allowed plugins to register a > ‘provider’ class that would allow free placement of a widget. A framework > akin to that — that allows *naming* plugin-defined widgets and referencing > those names for placement in layouts — would be supremely useful. > > Jake > > On Jul 30, 2024, at 5:04 PM, Thomas Passin <tbp1...@gmail.com> wrote: > > We've had several threads about layouts recently, since with the demise > of the nested splitter there's no way for a user to apply other layouts > except by using a script, and no way to return to a previous layout without > another script. Edward is off and running with his plans. I have been > working on scripts to create and remove layouts (which can't be done in > general with out a lot of new complexity). > > > What's been missing is much discussion of what the requirements for new > layouts should be. I've learned a lot as I've been working on a layout > restoration script, and I've thought about how I think things to work. I'd > like to invite your input too. Here's what I have come up with so far: > > A user should be able to: > 1. specify a default global startup layout using a setting. > 2. specify a per-outline startup layout using a setting. > 3. discover alternate layouts. > 4. change an outline's layout to one of the alternatives by command or > menu without re-opening the outline. > 5. return the current outline's layout to its default, preferably without > reloading the outline. > > A script writer should be able to: > 6. specify a new layout in a simple way. > 7. assign a command to activate a layout so that a user can use it. > 8. if necessary, write a teardown script that will delete all objects > created for that layout and associate the script with the layout. > 9. have a way for a plugin that defines layouts to make those layouts > known to a user. > > Leo should provide: > 10. a standard way for an instantiated layout to be deleted or inactivated > without leaving undeleted or dangling layout-specific objects. > 11. a standard way for new layouts to be made available. > > One or another of these may turn out not to be practical but I hope that > won't be the case. What else have I missed? > > -- > 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+...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/leo-editor/5f7dba63-083b-4dd7-aea0-2345f71d2c2fn%40googlegroups.com > > <https://groups.google.com/d/msgid/leo-editor/5f7dba63-083b-4dd7-aea0-2345f71d2c2fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/a9f69b69-c18a-410a-9eca-1cf53c9f6536n%40googlegroups.com.
