Note that the Viewrendered plugin suffers from the same problems as VR3 did. That is not surprising since the VR3 splitter code was taken directly from VR.
On Thursday, September 24, 2020 at 11:55:02 AM UTC-4 [email protected] wrote: > Here is the code for my experimental command to open VR3 with a fixed > layout. I came up with it after studying some of the nested splitter code > in LeoRef.py, and instrumenting some of the existing layouts. Note that I > use the declared constant string VR3_NS_ID for the nested splitter ID > (it's the string you suggested): > > @g.command('vr3-use-default-layout') > def open_with_layout(event): > vr3 = getVr3(event) > splitter = vr3.c.free_layout.get_top_splitter() > layout = {'orientation': 1, > 'content': [{'orientation': 2, > 'content': ['_leo_pane:outlineFrame', > '_leo_pane:logFrame'], > 'sizes': [0,0] > }, > '_leo_pane:bodyFrame', VR3_NS_ID > ], > 'sizes': [0,0,0] > } > splitter.load_layout(layout) > vr3.c.k.simulateCommand('vr3-update') > > I have de-compactified the layout dictionary to make it easier to read and > modify. > On Thursday, September 24, 2020 at 10:00:36 AM UTC-4 Edward K. Ream wrote: > >> On Wed, Sep 23, 2020 at 11:53 PM [email protected] <[email protected]> >> wrote: >> >> After a few minor changes, I have found that the problem behavior has >>> been reduced to one circumstance that I know about. If I open VR3 as a >>> free-floating window from the splitter, and then close it using either the >>> close box on its title bar, or <ALT-F4> (this is on Windows, and <ALT-F4> >>> is the standard Windows way to close a window from the keyboard), the next >>> time I re-open VR3 using the vr3-toggle command it opens as a >>> free-floating window with the title bar out of view at the top of the >>> screen. If this window is moved into full view using keyboard controls, >>> the title bar does not show the name of the associated outline. However, >>> when I close *this* free floating window using the vr3-toggle command >>> and then toggle it open again, it re-opens as an internal pane. >>> >> >> I have started to study Terry's free_layout code. It's not easy. I'll be >> looking for data that might indicate whether the QPane floats. >> >> [On Windows, a window whose title bar is off-screen can be moved by >>> pressing <ALT-Spacebar>, then <M>, then use the arrow keys to move it into >>> full view.] >>> >> >> Analogous keystrokes/commands exist on MacOS and Linux. >> >>> It is possible that previous use of my private experimental command >>> vr3-use-default-layout was necessary to arrive at this point, but I >>> can't undo it to be sure. At any rate, It's clear that closing a >>> free-floating window using other than VR3 commands causes some change in >>> what layout is applied by Leo, or how opening the pane is called. >>> >>> Note that I have not tried any of this on Linux yet. >>> >>> Anyone have any ideas about what might be going on here? >>> >> >> Not yet. Your comments will help guide my study. Imo, it's time to get >> #1686 <https://github.com/leo-editor/leo-editor/issues/1686> flattened, >> now that the free_layout code is the one and only way of managing Leo's >> panes. Your commands should probably be part of the mix. >> >> When I awoke this morning, I realized that the layout-related code in all >> of the VR plugins is probably useless. In fact, the FreeLayoutController >> class handles all layout-related stuff, without reference to the "layouts" >> top-level var in the VR plugins. I think this is as it should be, but I'll >> be double checking soon. >> >> I think it is acceptable and maybe even desirable for the VR3 pane to >>> open inside Leo's window instead of as a free floating window after it has >>> been closed, since 1) you can always open it free floating again using the >>> splitter bar context menu, and 2) How else could you tell Leo that you want >>> it to stop being a free floating window? I suppose that's just where docks >>> could have been useful, if only they could have been made to work correctly. >>> >> >> I agree. Otoh, it would be best to open floating windows exactly as they >> were, if this is possible. >> >> Terry's code is all custom machinery. Whether (or how) it handles >> floating windows is still a mystery. I'll be studying the code with this >> question in mind, among others. >> >> 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/868eae04-9905-42eb-8342-fb53132f21dfn%40googlegroups.com.
