On Wednesday, October 9, 2024 at 7:13:18 AM UTC-4 [email protected] wrote:
[email protected] schrieb am Dienstag, 8. Oktober 2024 um 01:55:20 UTC+2: Viktor, I've got all these cases of the missing VR/VR3 taken care of but before I push the changes up where you can try them, I'd appreciate your thoughts on a few things. - I assume this means that VR & VR3 do NOT have to be enabled at the same time in the future. - Correct ? Yes, that's right. Either one or both can be enabled. First, I have followed the way that the current system creates layouts that include VR or VR3. They set up a place for it but don't actually put VR/VR3 into it and show the widget unless it's already open and shown. It seems to me that if one asks for a layout that includes VR/VR3 that they would expect VR/VR3 will immediately be visible in that layout. What do you think? - Should VR/VR3 'content' be immediately visible - or - should the user explicitly request it ? - For me this is not an OR - but - an AND ! - I believe there are situations (e.g. single screen / small laptop, etc.) where the user should be able to toggle to save 'screen estate'. Yes, that's how I work. The commands "vr-toggle" and "vr3-toggle" switch them in and out of visibility. Second, I have some layouts that use VR and some that use VR3. I think that these layouts should (like, for example, "Big Tree") should open with VR3 if available otherwise with VR. That will be a little tricky to arrange but I think it can be done. Do you have an opinion here? - If VR3 is enabled, should it be prioritized over VR ? - I don't have a strong opinion on this issue - but - somehow it feels 'strange' to me to put plugin - dependencies / relationships into Leo's core code. This dependency is already in the core - F11 and some of the other "help-for" commands use VR3 for display if enabled, otherwise they use VR. I am concerned that having a "VR version and a "VR3" version of each layout would be confusing and cause cluttered menus. This is not a technical programming matter, of course. I have devised a small code change that can optionally (that is, a layout writer can choose to use the feature or not) use VR3 if enabled, VR otherwise. I've proposed a PR to add this feature, and we can see if it causes anyone problems. The third thing I would welcome your opinion on is about which layouts should be included in the core code vs which ones could be defined in @settings tree. The Layout-Demo outline uses a mix of both. My thinking is that some layouts may only be useful to a few users (like me or you!) whereas others would see more widespread use. Of course new layouts can be created by anyone - if they can do the small amount of scripting - and put into an @settings tree. I'm unsure where to draw the line between core commands and non-core ones. What is your opinion? - Which ~ layouts ~ should be offered / provided by Leo's core ? - I tried out all layouts currently offered by Leo's core. - See "Log-001" below - IMO 'layout-big-tree' & 'layout-vertical-thirds2' are quite special - and - could be just documented as examples. I included all the layouts the Edward had already built in ... although it's hard for me to see how to use some of them as a practical matter. I also included the layout I prefer to start out with, as well as one to swap the log frame between the main and secondary splitters. If anyone can come up with any others, it's easy enough to create them. New ones can be added to one's myLeoSettings.leo file without needing to change Leo's core code at all. Edward added code so that the plugin controller can know about the new module. I didn't realize it but this automatically causes the plugins menu to include a menu with all the new layout commands. I had thought we could add such a menu to LeoSettings.leo but this won't be necessary now. You can still use the Layout-Demo outline but it's not necessary any more. With kind regards, Viktor Thank you so much for your testing and suggestions! -- 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/8b4fce25-e61a-482d-8a01-77cd51d9ab9fn%40googlegroups.com.
