About changes to VR3

[Edward K. Ream]

I have been stepping on Thomas's toes regarding the VR3 plugin. It's time to sort things out.

I propose that Thomas be fully responsible for the VR3 plugin from here on. In other words, I promise not to touch the code. I have just delegated #1685 to Thomas alone.

The question is, have I already messed up Thomas's code? I think not, as I shall now explain in detail.

Recent changes

The following script diffs all files between the latest commit to devel and Thomas's latest commit:

import leo.commands.editFileCommands as efc

efc.GitDiffController(c).diff_two_revs(
    rev1='aaf1825c7bb', # Thomas's last commit.
    rev2='bf81d8e09da', # Latest devel commit
    directory=None,
)

21 files appear in the diffs, but only changes to the free_layout.py, nested_splitter.py and viewrendered3.py plugins are relevant here. Here is a careful summary of those diffs:

free_layout.py

Remove dock-related code from four free-layout commands. This should have no effect on VR3.

nested_splitter.py

Move the ns.get_title method to a separate node. Again, this should have no effect on VR3.

viewrendered3.py

The following are the changes I see after carefully studying the diffs:

- [No effect on VR3] Remove qt docks code.

- [No effect on VR3] Change:
    fn = g.os_path_expandExpression(fn, c=c)

to:

    fn = c.expand_path_expression(fn)

- ns_provide: This method is the all-important factor method. It creates one Qt pane per commander. That's the way it has always been.

Note: The new code uses self.ns_provider_id() instead of '_leo_viewrendered3'. See below.

- Added ns_provider_id(self): return f"vr3_id:{self.c.shortFileName()}".

Thomas, you might want to change this back so it returns '_leo_viewrendered3'. However, ns_provide will probably not be affected.

- ns_provides: return [('Viewrendered 3', self.ns_provider_id())]

This shouldn't need to change. Just change ns_provider_id() as suggested above.

Requested change

At present, VR3 layouts conflict with layouts for the other VR plugins. The fix is easy: VR3 should use the 'viewrendered3_default_layouts' key instead of 'viewrendered_default_layouts' key.

Suggested changes

Thomas, it might be clearer if you change ns_provider_id so it returns '_leo_viewrendered3'. This should guarantee that the new code is equivalent to your code before I started messing with it :-)

The present (new) version of ns_title is:

def ns_title(self, id_):
    if id_ != self.ns_provider_id():
        return None
    filename = self.c.shortFileName() or 'Unnamed file'
    return f"Viewrendered 3: {filename}"

For #1683, the title should probably just be something like "Viewrendered 3". I'm not sure how often this is called.

Summary

This post has carefully considered all recent changes to the VR3 plugin.

The new code is likely completely equivalent to rev bf81d8e09da. However, some suggested changes would make the equivalence more obvious.

Thomas, I have delegated #1683 and all future work on VR3 to you. I am happy to answer any questions, or to contribute code. I have one request, namely that the layouts for the VR and VR3 plugins should be distinct. Using 'viewrendered3_default_layouts' as the c.db key should suffice.

Edward

[tbp1...@gmail.com]

For VR3, I just copied the code from VR.  I didn't know anything about how it all worked, the ``provides`` code and all, so I didn't make any changes.  I seem to remember that at some point, I did change ``viewrendered`` to ``viewrendered3`` somewhere in the ``provider`` class, but I might not have gotten all the references (and I didn't know what significance if any it would have).  I have hotkeyed VR to <ALT-F10>, and VR3 to <ALT-0>. so when I do enable VR I can pop each one up individually without needed to do an <ALT-X> command.  I made sure that all the VR3 commands start with ``vr3-`` so they don't conflict with the equivalent VR ``vr-`` commands.

On Tuesday, September 22, 2020 at 12:23:02 PM UTC-4 Edward K. Ream wrote:

...

free_layout.py

Remove dock-related code from four free-layout commands. This should have no effect on VR3.

nested_splitter.py

Move the ns.get_title method to a separate node. Again, this should have no effect on VR3.

viewrendered3.py

The following are the changes I see after carefully studying the diffs:

- [No effect on VR3] Remove qt docks code.

- [No effect on VR3] Change:
    fn = g.os_path_expandExpression(fn, c=c)

to:

    fn = c.expand_path_expression(fn)

- ns_provide: This method is the all-important factor method. It creates one Qt pane per commander. That's the way it has always been.

Note: The new code uses self.ns_provider_id() instead of '_leo_viewrendered3'. See below.

- Added ns_provider_id(self): return f"vr3_id:{self.c.shortFileName()}".

Thomas, you might want to change this back so it returns '_leo_viewrendered3'. However, ns_provide will probably not be affected.

- ns_provides: return [('Viewrendered 3', self.ns_provider_id())]

...

[tbp1...@gmail.com]

Unfortunately, changing ns_provider_id to return a constant string did not cause the VR3 pane to be global.

[tbp1...@gmail.com]

The upshot is :

1) Making the suggested change(s) does not give us a global VR3 window;

2) All these ``ns_provider`` things seem to apply only when a floating window is opened from the splitter bar context menu.  Otherwise they are not even activated.

3. So these ``ns_provider`` methods don't bear on how to get VR3 to open in a internal pane instead of a floating window.

[tbp1...@gmail.com]

After I deleted .leo\db folder, VR3 finally opened in an internal frame. Opening a floating VR3 window from the splitter context menu opened a second, floating window while leaving the previously opened internal pane alone.  I found I had to delete both databases in the db folder to get this to work reliably.

I'm speculating that I had some layout data left over from using --use-docks that was getting reused, but who really knows?

All these instances were still specific to the selected Leo outline.  I'm finding that I don't mind that so much for the internal pane.  I can have an open VR3 in several outlines, and when I select an outline, its instance of VR3 shows rendering for that pane.  So that's not really confusing or annoying, unlike having to have multiple free-floating windows open at the same time for the several outlines, which *is* annoying.

[tbp1...@gmail.com]

We are not out of the woods yet.  I have found that unpredictably an outline will open VR3 in a floating window, and then there doesn't seem to be a way to get it to open in the internal pane, not even closing and reopening Leo.

When this happens, the title bar does not show that name of the outline file being rendered.   This must be a clue, and I'll see if it leads me anywhere.

[vitalije]

If my memory is correct, I've added some years ago code to the free layout to allow Leo to remember layout of panes. Before that if one opens vr pane it would change position of splitters and after closing pane body would become smaller than it used to be before opening vr pane. That was annoying and there was a feature request for preserving layout.

When you open some pane in a separate window, it is usually removed from the nested splitter and I guess this new layout is saved, so when you reopen Leo the pane is missing from the layout. User needs to use eastern egg menu to split some area and then to add vr3 pane to the newly formed part of layout.

This two step action can be turned into a new command. If you want to programmatically open vr3 pane inside main Leo window, you need first to add new area by splitting an existent pane and then to set vr3 as a provider for the newly created area.

HTH Vitalije

[Edward K. Ream]

On Tue, Sep 22, 2020 at 5:42 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Unfortunately, changing ns_provider_id to return a constant string did not cause the VR3 pane to be global.

That's expected. ns_provider is the factory method. If you want a single, global, VR3 pane, ns_provider should return a singleton Qt pane. That is, ns_provider should not allocate per-commander panes, but should allocate only a single pane the first time it is ever called, and thereafter return that single pane.

Edward

[Edward K. Ream]

On Tue, Sep 22, 2020 at 1:03 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

For VR3, I just copied the code from VR.  I didn't know anything about how it all worked, the ``provides`` code and all, so I didn't make any changes.  I seem to remember that at some point, I did change ``viewrendered`` to ``viewrendered3`` somewhere in the ``provider`` class, but I might not have gotten all the references (and I didn't know what significance if any it would have).  I have hotkeyed VR to <ALT-F10>, and VR3 to <ALT-0>. so when I do enable VR I can pop each one up individually without needed to do an <ALT-X> command.  I made sure that all the VR3 commands start with ``vr3-`` so they don't conflict with the equivalent VR ``vr-`` commands.

All good. In addition, the layout should also not conflict with VR.

Edward

[Edward K. Ream]

On Tue, Sep 22, 2020 at 8:04 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

The upshot is :

1) Making the suggested change(s) does not give us a global VR3 window;

ns_provide must allocate and return a global singleton.

2) All these ``ns_provider`` things seem to apply only when a floating window is opened from the splitter bar context menu.  Otherwise they are not even activated.

I think that's right.

3. So these ``ns_provider`` methods don't bear on how to get VR3 to open in a internal pane instead of a floating window.

The Easter Egg interface has an item called "Restore default layout". I think that's the way.

Edward

[Edward K. Ream]

On Tue, Sep 22, 2020 at 9:16 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

After I deleted .leo\db folder, VR3 finally opened in an internal frame. Opening a floating VR3 window from the splitter context menu opened a second, floating window while leaving the previously opened internal pane alone.  I found I had to delete both databases in the db folder to get this to work reliably.

I'm speculating that I had some layout data left over from using --use-docks that was getting reused, but who really knows?

--trace=cache will give you some idea of what is going on.

All these instances were still specific to the selected Leo outline.  I'm finding that I don't mind that so much for the internal pane.  I can have an open VR3 in several outlines, and when I select an outline, its instance of VR3 shows rendering for that pane.  So that's not really confusing or annoying, unlike having to have multiple free-floating windows open at the same time for the several outlines, which *is* annoying.

I agree. Per-commander (per-outline) VR3 panes aren't a problem unless they are free floating.

So suppose you stick with the present scheme. The present ns_title disambiguates the free-floating window. So the only problem is saving/restoring the free floating vr3 window.

Alas, saving a "float-vr3" layout after creating a floating vr3 pane doesn't seem to work.

Hmm.  The global layouts dict is never used! That must be wrong, because the free_layout code in the FreeLayoutController (flc) class never accesses 'layouts'. However, flc.loadLayouts does access the 'ns_layouts' key from g.app.db and the '_ns_layout' keys from c.db.

Summary

For now, the only change I would like you to make right now is to change 'viewrendered_default_layouts' to 'viewrendered3_default_layouts' in ns_provide. This almost certainly will have no immediate effect, but it should be done sometime.

Saving and restoring free_layout layouts is a separate issue from VR3. I don't understand what VR3 is expected to do, if anything. I have just created #1686 for this.

Edward

[Edward K. Ream]

On Tue, Sep 22, 2020 at 10:01 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

We are not out of the woods yet.  I have found that unpredictably an outline will open VR3 in a floating window, and then there doesn't seem to be a way to get it to open in the internal pane, not even closing and reopening Leo.

Try either the "Restore initial layout" or the "Restore default layout" from the splitter (Easter Egg) menu.

Edward

[Edward K. Ream]

Thanks for this. I don't think a new command is what we want. Instead, we want the free_layout code to restore the layout as it was when Leo last exited (regardless of save).

I suspect there are lots of tricky details involved. For example, if Leo opens with two .leo files showing, we want to restore layouts for each .leo file. This seems like the only way to restore floating VR3 layouts for each file.  But this is just a guess. Only studying the code and doing experiments will tell us for sure.

Edward

[tbp1...@gmail.com]

Neither one returns VR3 to the internal pane.

[tbp1...@gmail.com]

Some progress to report.  I created a layout that puts VR3 into the right-hand pane.  This is my normal layout with the outline and log panes at the left, body center, and VR3 at right.  I wrote a command to load that layout.  No matter what has gone wrong with the layouts (like VR3 in a free floating window with the title bar off-screen), this will open VR3 in the right hand pane.

Once I invoke this command, then VR3 will open, close, and re-open in the right pane using the command vr3-show or vr3-toggle.  If I open it as a free floating window using the splitter bar context menu, VR3 will open in its own window and its title bar will include the name of the leo outline.

However, having done that once, when I close and reopen VR3 using the vr3-toggle command, it will re-open as a free-floating window with the title bar off-screen, and when moved on screen the title bar does not contain the outline's name.  In this state, the only way to get VR3 to open in the internal pane again is to invoke the new vr3-use-default-layout command.

Note that this new command is not in the repo - for the time being it's just for my own experimentation.

[tbp1...@gmail.com]

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.

[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.]

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?

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.

[Edward K. Ream]

On Wed, Sep 23, 2020 at 2:15 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Some progress to report.  I created a layout that puts VR3 into the right-hand pane.  This is my normal layout with the outline and log panes at the left, body center, and VR3 at right.  I wrote a command to load that layout.  No matter what has gone wrong with the layouts (like VR3 in a free floating window with the title bar off-screen), this will open VR3 in the right hand pane.

Excellent!

Once I invoke this command, then VR3 will open, close, and re-open in the right pane using the command vr3-show or vr3-toggle.  If I open it as a free floating window using the splitter bar context menu, VR3 will open in its own window and its title bar will include the name of the leo outline.

Good to know.

However, having done that once, when I close and reopen VR3 using the vr3-toggle command, it will re-open as a free-floating window with the title bar off-screen, and when moved on screen the title bar does not contain the outline's name.  In this state, the only way to get VR3 to open in the internal pane again is to invoke the new vr3-use-default-layout command.

Thanks for this progress report.  I'll say more in my reply to your next post.

Edward

[Edward K. Ream]

On Wed, Sep 23, 2020 at 11:53 PM tbp1...@gmail.com <tbp1...@gmail.com> 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 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

[tbp1...@gmail.com]

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.

[tbp1...@gmail.com]

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.

[Edward K. Ream]

On Thu, Sep 24, 2020 at 10:55 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Here is the code for my experimental command to open VR3 with a fixed layout. 

Thanks for this. It will definitely help me in my studies.

Edward

[Edward K. Ream]

On Thu, Sep 24, 2020 at 10:57 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

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.

Yes. I am likely to remove the unused layout stuff from all the VR plugins. I'll create separate issues and PR's for all aspects of this project, so we can evaluate each independently. First, though, I'll be studying and experimenting.

Edward

[tbp1...@gmail.com]

Using non-zero sizes in my layout might be better.  Instead of 'sizes': [0,0,0], 'sizes': [200,200,200] would probably be better. Using "0" sizes may invite the layout machinery to make odd choices once in a while.

[Edward K. Ream]

On Thu, Sep 24, 2020 at 11:09 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Using non-zero sizes in my layout might be better.  Instead of 'sizes': [0,0,0], 'sizes': [200,200,200] would probably be better. Using "0" sizes may invite the layout machinery to make odd choices once in a while.

I agree.

Edward