On Wednesday, September 30, 2020 at 11:57:38 AM UTC-4 Edward K. Ream wrote:
> On Tue, Sep 29, 2020 at 10:23 PM [email protected] <[email protected]> > wrote: > > When a pane is opened as a toplevel window by using the Open Window >> context menu, that pane is not a part of the ordinary nested splitter >> layout, so far as I can tell. How can this pane be accessed? >> > > When I execute one of these commands, the pane becomes a floating window. > However, it does not become a floating window when Leo is reloaded. > That's what I see, too. The relevant code is dense and not easily understood or summarized. I'm not > sure how much more effort I can justify in this area. I'll spend some more > time on it, but probably not a lot more. > > Let me summarize what I think I know at present: > > 1. Terry's code has no machinery to represent floating windows, as is > shown in the two methods I discussed yesterday, namely ns.get_layout and > ns.get_saveabke layout. It might be relatively straightforward to add a > 'floating' key to the python dicts returned from those methods. > I haven't been particularly interested in floating windows, until I started getting some with VR3 without intending to. If the main Leo window obscures part of the floating window, I find that annoying because I have to constantly bring it to the front. But I suppose that some might want it to appear in a second monitor - which I don't have - so one way or another the floating window case probably ought to behave itself. ... > 3. On startup, flc.loadLayouts creates free-layout-load-{layout_name} commands that will load the named layouts. So (modulo floating > panes) there *already* is an easy way to load any layout you want, and you can bind any key to the commands using @button or > @command nodes, and possibly even in myLeoSettings.leo. Yes, I saw that the load_layout code calls your pane's ns_provide(), which returns your pane's widget if it isn't there already. And I can see that a floating top level window isn't included in this process. Like you, I think this machinery works pretty well. But somewhere there must be some reference to the floating window, and I haven't tracked it down yet. *> Summary* ... > At present, Terry's code does not remember whether panes are floated. It might be possible to add that capability, but imo that is not a > high priority. Agreed. > The question of whether VR3 should be global or local turns out to be way tricky. I have refactored flc.loadLayouts in order to get a grip > on this question, but everything is still murky. I would like to do an ENB on this subject. Maybe today or tomorrow. I see that there is a way to make the pane it a singleton, but that might get tricky if VR3 wants to change the type of widget (I.e., to a plain text widget). I don't really have a problem with a separate widget per outline (except possibly for a floating window). But I have started to wonder if the current VRx code could be leaking widgets. It seems that they can be created frequently without anyone being able to notice. When ns_provide() runs, a new widget is created and returned. I *think* that when this gets assigned it replaces the previous assignment (I mean in Terry's code). If this is correct, then the previous widget ought to be available for garbage collection, but I don't feel confident about that yet. -- 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/813ebc10-70cb-41f4-8d94-734d1d297c51n%40googlegroups.com.
