Viewrendered3 Fails to Start With Leo 6.2-b1 But Works With Leo 6.1-final

[Thomas Passin]

Windows 10, Python 3.8.

Running Leo 6.2-b1, VR3 fails to create its toolbar (which causes VR3 to fail), but the very same file, viewrendered3.py, works as expected running Leo 6.1-final.  Most of my development used Leo 6.1-final, though using Leo from the devel branch from several weeks ago worked right too.

I am switching between my default Leo 6.1-final and the new 6.2-b1 by setting the PYTHONPATH environmental variable to nothing, or to the directory where my 6.2-b1 repo is.  So all the installed site-packages are the same.  They are using the same MyLeoSettings file.

This difference is hard for me to understand.  I will see if I can track down what is going wrong, but I'm hoping someone has an idea here! The toolbar is a QT5 widget.

[Edward K. Ream]

On Sun, Mar 15, 2020 at 10:53 PM Thomas Passin <tbp1...@gmail.com> wrote:

Running Leo 6.2-b1, VR3 fails to create its toolbar (which causes VR3 to fail), but the very same file, viewrendered3.py, works as expected running Leo 6.1-final.

I'll look into this. VR3 must either work with the 6.2 code base or be delayed to 6.3.

Edward

[Edward K. Ream]

On Monday, March 16, 2020 at 5:39:23 AM UTC-5, Edward K. Ream wrote:

> I'll look into this.

Fixed in both the 6.2 and devel branches.

Thomas, I'm not sure why this was a mysterious problem for you. I continue to suspect something is not right on your end.

Please verify, using gitk, that you see the changes I made in both the 6.2 and devel branches.

Edward

[Thomas Passin]

There is one specific thing that is failing:

g.app.dock is returning False.  When that happens, the rest of create_pane() gets skipped (and of course my plugin won't work).  It is supposed to be returning True when docks are in use.

This happens when I start Leo with --init-docks.  When I start with --use-docks, then g.app.dock returns True, and the plugin works. There is another issue that shows up then - it's not finding its default stylesheet - but that's minor.

Leo's startup info:

Leo 6.2-b1, 6.2 branch, build a2a4828981
2020-03-15 10:22:24 -0500
Python 3.8.0, PyQt version 5.14.0
Windows 10 AMD64 (build 10.0.18362) SP0

[Thomas Passin]

On Monday, March 16, 2020 at 6:58:21 AM UTC-4, Edward K. Ream wrote:

Thomas, I'm not sure why this was a mysterious problem for you. I continue to suspect something is not right on your end.

Please verify, using gitk, that you see the changes I made in both the 6.2 and devel branches.

The problem I'm having is that my repo in my account on Github somehow got messed up, and I haven't been able to nuke it, repair it, or get it to fully update itself from the Leo upstream.  At the moment, I have cloned Leo again to my computer, and that is the version I'm using to debug the plugin.  Without my Github repo working, and without commit privileges to the Leo repo, I don't know how I'm going to do a pull request.  And obviously I shouldn't have commit privileges to the Leo repo at this time!

[Thomas Passin]

On Monday, March 16, 2020 at 8:08:57 AM UTC-4, Thomas Passin wrote:

There is one specific thing that is failing:

g.app.dock is returning False.  When that happens, the rest of create_pane() gets skipped (and of course my plugin won't work).  It is supposed to be returning True when docks are in use.

This happens when I start Leo with --init-docks.  When I start with --use-docks, then g.app.dock returns True, and the plugin works.

I started to use --init-docks when my body and tab panes got so messed up they were unusable and I couldn't get them into a sensible configuration again.

[Edward K. Ream]

On Mon, Mar 16, 2020 at 7:13 AM Thomas Passin <tbp1...@gmail.com> wrote:

On Monday, March 16, 2020 at 6:58:21 AM UTC-4, Edward K. Ream wrote:

Thomas, I'm not sure why this was a mysterious problem for you. I continue to suspect something is not right on your end.

Please verify, using gitk, that you see the changes I made in both the 6.2 and devel branches.

The problem I'm having is that my repo in my account on Github somehow got messed up, and I haven't been able to nuke it, repair it, or get it to fully update itself from the Leo upstream. 

Alright. I've fixed the problem in vr3. Hope you recover from your problems :-)

Edward

[Edward K. Ream]

On Mon, Mar 16, 2020 at 7:15 AM Thomas Passin <tbp1...@gmail.com> wrote:

On Monday, March 16, 2020 at 8:08:57 AM UTC-4, Thomas Passin wrote:

 

I started to use --init-docks when my body and tab panes got so messed up they were unusable and I couldn't get them into a sensible configuration again.

Just delete the entire ~/.leo/db folder.

Edward

[Thomas Passin]

On Monday, March 16, 2020 at 8:32:24 AM UTC-4, Edward K. Ream wrote:

Alright. I've fixed the problem in vr3. Hope you recover from your problems :-)

Thanks.  In addition, I found two other issues, both fixed in the attached zip file:

1) The name of the RsT stylesheet was obsolete( i.e., wrong);

2) One line you added to the MD conversion was wrong:

h = g.toUnicode(s)  # EKR.

Should have been:

h = g.toUnicode(h)  # EKR.

This caused display of the raw text instead of the MD-rendered text.

With these fixes, I think we're good to go.

[Edward K. Ream]

On Mon, Mar 16, 2020 at 8:55 AM Thomas Passin wrote:

I found two other issues, both fixed in the attached zip file:

Your copy of VR3.py corrected the call to g.toUnicode(s).

Your copy of qt_gui.py was, once again, not formatted properly. Neither file changed the name of the stylesheet.

So I've only changed the call to g.toUnicode. The change is in both devel and 6.2.

Edward

[Thomas Passin]

On Monday, March 16, 2020 at 10:56:51 AM UTC-4, Edward K. Ream wrote:

Your copy of qt_gui.py was, once again, not formatted properly. Neither file changed the name of the stylesheet.

I probably should not have included the qt_gui.py at all.  I just wanted to make sure it didn't get deleted.  I think I had not made sure that my copy was updated to yours, so a big blush here.

The files did not change the name of the stylesheet, but the actual RsT stylesheet file in the plugins/viewrendered directory was corrected.  If it is wrong, the plugin will still work but the results will look uglier than need be.  The correct file name is "vr3_rst.css".

 

So I've only changed the call to g.toUnicode. The change is in both devel and 6.2.

Great, that was the main thing.

[Edward K. Ream]

On Mon, Mar 16, 2020 at 10:57 AM Thomas Passin <tbp1...@gmail.com> wrote:

> The correct file name is "vr3_rst.css".

So I should change leo_vr3.css to vr3_rst.css?

Edward

[Thomas Passin]

Yes, please do that. I just looked at the viewrendered.py file in the Leo repo, and I agree that it's got the desired change. So just the file rename.

[Matt Wilkie]

The problem I'm having is that my repo in my account on Github somehow got messed up, and I haven't been able to nuke it, repair it, or get it to fully update itself from the Leo upstream.

Thomas I think maybe what happened is that at some point in history a new local branch named "devel" was created based on "master" instead of checking out the upstream "devel".

To clean up the situation I might try:

1. Ensure local repo is up to date with https://github.com/tbpassin/leo-editor
2. Archive local repo into a zip (or whatever) and then delete
   
3. On GitHub delete https://github.com/tbpassin/leo-editor under [settings]. You can import from your local repo later if you decide it has something important.
4. Create a new fork from https://github.com/leo-editor/leo-editor and clone to your local machine.
5. Checkout Devel branch
6. Create your branch from Devel and bring in your work.
   

The purpose of archiving and deleting in #2 instead of moving or renaming is to ensure Github Desktop can't possiblly seeing anything but the new fork.

-matt

[Edward K. Ream]

On Mon, Mar 16, 2020 at 11:36 AM Thomas Passin <tbp1...@gmail.com> wrote:

So I should change leo_vr3.css to vr3_rst.css?

Yes, please do that.

Done in 6.2 and devel branches.

Edward

[Edward K. Ream]

On Mon, Mar 16, 2020 at 3:42 PM Matt Wilkie <map...@gmail.com> wrote:

The problem I'm having is that my repo in my account on Github somehow got messed up, and I haven't been able to nuke it, repair it, or get it to fully update itself from the Leo upstream.

Thanks, Matt, for these suggestions. Hope they work.

Edward

[Thomas Passin]

Thank you Matt.  I followed your suggested steps, and they worked.  I now have an all-new fork.  One of the missing things for me (before you wrote) was how to delete my entire GitHub fork.  I don't know how long that would have taken me to find if you had not pointed me to Settings.

[Edward K. Ream]

On Tue, Mar 17, 2020 at 12:32 PM Thomas Passin <tbp1...@gmail.com> wrote:

Thank you Matt.  I followed your suggested steps, and they worked. 

Excellent.

Edward

[Matt Wilkie]

Thank you Matt.  I followed your suggested steps, and they worked.  I now have an all-new fork.  One of the missing things for me (before you wrote) was how to delete my entire GitHub fork.  I don't know how long that would have taken me to find if you had not pointed me to Settings.

Oh good. I'm glad I was able to leverage some of my scar tissue to help! I'm really not that knowledgeable about git, but in this case there was enough. :)

-matt

[Thomas Passin]

One thing that made it a bit easier is that my work on VR3 took place outside of my Github clone.  My development tree is in Mercurial on my own computer.  I have a script hot-keyed to F5 that copies the files to the Github clone, and the only work I was doing was on VR3 - no other branches were getting changed.  So I was able to just delete the clone without worrying if I  was going to lose some strategic change.