weirdness when trying to enable a new (or any?) plugin

[jkn]

I feel like I am being a bit dim here...

I'm trying to enable the freewin plugin (I am actually also trying viewrendered/viewrendered3, but 'backed off' to freewin, because I seem to be having fundamental plugin issues.

- I have an @settings node '@enabled-plugins' in myLeoSettings.leo

- the body of this has several plugins already listed (which I hardly ever/never use)

- I added a 'freewin' line

- after restarting Leo, I run a node with "g.es(g.app.config.getEnabledPlugins())" (NB: docs says 'g.app.gui.getEnabledPlugins()"; I will correct this later)

- nothing is shown! my @enabled-plugins node does not appear to be read.

- so ... I put a similar node under @settings in a particular file

- now I can run g.es(g.app.config.getEnabledPlugins()) and see 'freewin' in the log pane.

- however...

- show-commands does not show z-open-freewin

- show-commands from the minibuffer does not list this command

- pressing a @utton with "c.executeMinibufferCommand('z-open-freewin')" gives "no command-function for z-open-freewin"

- nothing happens if I try to run this (non--existent?) command from the minibuffer.

I can start Leo from the command line and can see no errors output ... although there does seem to be a discrepancy between what plugins are enabled between starting like this, and from a desktop shortcut.

This seems weird ... am I missing something fundamental here?

running Leo 6.8.2-devel on Linux FWIW.

Thanks, jon N

[Thomas Passin]

On Sunday, November 3, 2024 at 3:50:44 PM UTC-5 jkn wrote:

I feel like I am being a bit dim here...

I'm trying to enable the freewin plugin (I am actually also trying viewrendered/viewrendered3, but 'backed off' to freewin, because I seem to be having fundamental plugin issues.

You have to include the ".py" extension in the enabled-plugins body.  It the extension is present Leo will look in the leo/plugins directory.  If it's absent, Leo will try to import the module from the known sys.path locations.  So for freewin, the entry in enabled-plugins needs to be: freewin.py -

plugins_menu.py
viewrendered.py
viewrendered3.py
contextmenu.py
nav_qt.py
mod_scripting.py
mod_autosave.py
python_terminal.py
qt_layout.py
quicksearch.py
freewin.py
rpcalc.py
leo_to_html.py

 

- I have an @settings node '@enabled-plugins' in myLeoSettings.leo

- the body of this has several plugins already listed (which I hardly ever/never use)

- I added a 'freewin' line

- after restarting Leo, I run a node with "g.es(g.app.config.getEnabledPlugins())" (NB: docs says 'g.app.gui.getEnabledPlugins()"; I will correct this later)

Running that exact expression, I see all the plugins I've enabled, including freewin:

plugins_menu.py
viewrendered.py
viewrendered3.py
contextmenu.py
nav_qt.py
mod_scripting.py
mod_autosave.py
python_terminal.py
qt_layout.py
quicksearch.py
freewin.py
rpcalc.py
leo_to_html.py

 

- nothing is shown! my @enabled-plugins node does not appear to be read.

- so ... I put a similar node under @settings in a particular file

- now I can run g.es(g.app.config.getEnabledPlugins()) and see 'freewin' in the log pane.

- however...

- show-commands does not show z-open-freewin

It never occurred to me to enable it locally only for one outline so I haven't tested for this. Off-hand I don't see why the commands wouldn't be present. I just went to one of my Linux VMs and tried it. the z-open-freewin command was present in all outlines, not just the one where I had put the enabled setting.  That surprised me.

[jkn]

Hi Thomas

    hmm... I have not had the .py in the list of plugins, based on ... the documentation. I will try to find the link.

> It never occurred to me to enable it locally only for one outline so I haven't tested for this.

I also found this option in the docs ... I was mildly surprised. But if my node in the local file is

@enabled-plugins  # content: freewin

(rather than freewin.py), it is  bit strange that that 'seems to work', albeit for some very-reduced version of 'work' (ie. just adds 'freewin' to the output of g.app.config.getEnabledPlugins())

> I just went to one of my Linux VMs and tried it. the z-open-freewin command was present in all outlines, not just the one where I had put the enabled setting.  That surprised me.

Yes, I was also experimenting with the 'scope' of plugins loaded like that, but didn't want to ask or mention it until I had got the basics sorted...

Hmm, I see I may have misread the documentation:

"""

https://leo-editor.github.io/leo-editor/plugins.html

You can enable plugins by file name or by module name: - Leo looks in the leo/plugins directory for names ending in .py. - Leo uses imports a module directly for names that do not end in .py, so you can load plugins from any path on PYTHONPATH, including paths given in sitecustomize.py.

"""

^^^^ if this is intended to mean what you say, then I think it could be written clearer.

The .pyc files in my plugins/ directory are extremely old, I am sure they predate anything in myLeoSettings.leo ...

I will experiment a bit and report back

Thanks, J^n

[Thomas Passin]

On Sunday, November 3, 2024 at 5:06:35 PM UTC-5 jkn wrote:

The .pyc files in my plugins/ directory are extremely old, I am sure they predate anything in myLeoSettings.leo ...

All .pyc files with Python 3.x go into a __pycache__ folder (I don't know if this started with Python 3.0 or with a later version of 3.x). If you have any that aren't, they might date back to Python 2 days.  Could that really be?

[jkn]

That use of __pycache__ started later than Python 3.0, I am pretty sure. Just to further confuse myself, I am actually jumping between two machines; one has .pyc files only in __pycache__, the other has some 'alongside' the .py files (2017!). Bu I suspect none of this is relevant to what I am seeing. It might possibly indicate that perhaps the behaviour (about requiring plugin name to have .py at the end) has changed over the years ... not sure.

Anyway - after putting 'freewin.py' in myLeoSettings.leo (and installing QtWebEngineView for PyQt6 - interestingly VR3 does not seem to give a warning if this is not installed) - I seem to be making progress, both with VR3 and with Freewin.

Curiously, I can now no longer replicate the reported behaviour! If I have an unsuffixed 'freewin' at the end of my @enabled-plugins, ... g.app.config.getEnabledPlugins()) now shows the other ones, with 'freewin' at the end, even though nothing has been installed for that and no z-open-window command is available. Is something cached here??

That seems a bizarre buglet, but I am not going to pursue it for now. I think I will submit a small PR with slight documentation clarification.

Anyway, I seem to be progressing, thanks...

    J^n

[Thomas Passin]

On Sunday, November 3, 2024 at 5:55:10 PM UTC-5 jkn wrote:

Anyway - after putting 'freewin.py' in myLeoSettings.leo (and installing QtWebEngineView for PyQt6 - interestingly VR3 does not seem to give a warning if this is not installed) - I seem to be making progress, both with VR3 and with Freewin.

Freewin will fall back to using a QTextBrowser for the rendered view if QWebEngineView isn't installed, and it should emit a message about that.  VR3 can't work without a QWebEngineView, and it's supposed to emit a message about a missing QWebEngineView .  Maybe some recent change has stepped on the message, but I don't recall any changes in that part of the code.

[jkn]

Hmm, slightly separate point, but now I am trying to replicate things (enabling viewrendered3) on my Windows machine...

I am getting a Windows Error popup: ... Qt6WebEngineCore.dll was not found...

Leo itself doesn't have an error from vr3.

I've tried to install/re-install a few things via pip, but no success. Any pointers?

Thanks, jon N

[Thomas Passin]

On Monday, November 4, 2024 at 6:51:53 AM UTC-5 jkn wrote:

Hmm, slightly separate point, but now I am trying to replicate things (enabling viewrendered3) on my Windows machine...

I am getting a Windows Error popup: ... Qt6WebEngineCore.dll was not found...

Leo itself doesn't have an error from vr3.

I've tried to install/re-install a few things via pip, but no success. Any pointers?

Post or compare your output  for

C:\Users\tom>py -m pip list |find /i "qt"
PyQt6                         6.7.0
PyQt6-QScintilla              2.14.1
PyQt6-Qt6                     6.7.2
PyQt6-sip                     13.6.0
PyQt6-WebEngine               6.7.0
PyQt6-WebEngine-Qt6           6.7.2
PyQt6-WebEngineSubwheel-Qt6   6.7.2

That last line puzzles me.  I don't  know why pip is listing it since it seems to be an auxiliary folder used during install.  I don't remember seeing it in past listings. It isn't included in the listing for my older Python 3.11 installation.

Here are some possibilities:

1. Before trying to re-install the PyQt6 packages, go to your site-packages directory and delete all directories with "Qt6" in their names.

C:\Users\tom>dir AppData\Roaming\Python\Python312\site-packages |find /i "qt6"
06/25/2024  10:54 PM    <DIR>          PyQt6
06/25/2024  10:54 PM    <DIR>          PyQt6-6.7.0.dist-info
06/25/2024  10:54 PM    <DIR>          PyQt6_QScintilla-2.14.1.dist-info
06/25/2024  10:54 PM    <DIR>          PyQt6_Qt6-6.7.2.dist-info
06/25/2024  10:54 PM    <DIR>          PyQt6_sip-13.6.0.dist-info
06/25/2024  10:54 PM    <DIR>          PyQt6_WebEngine-6.7.0.dist-info
06/25/2024  10:54 PM    <DIR>          PyQt6_WebEngineSubwheel_Qt6-6.7.2.dist-info
06/25/2024  10:54 PM    <DIR>          PyQt6_WebEngine_Qt6-6.7.2.dist-info

PyQt might have been installed installed in the system's site packages instead of the user's:

C:\Users\tom>dir AppData\local\Programs\Python\Python312\Lib\site-packages |find /i "qt6"

These are the standard locations for user and system site-package directories.  I normally install Qt6 with --user, so my Qt6 files are in the user location.

2. There could be a mixed condition where different versions got installed into the system and user locations.  I had that once. One of them should go away before re-installing PyQt to the other location.

3. Create a new virtual environment and install Leo into it.  Remember, with a venv on Windows you don't need to source the activate command, you just execute it directly.

[jkn]

C:\Users\nicoll\leo-editor>python3 -m pip list | find /i "qt"
PyQt5                         5.15.10
PyQt5-Qt5                     5.15.2
PyQt5-sip                     12.13.0
PyQt6                         6.7.1
PyQt6-Qt6                     6.7.3
PyQt6_sip                     13.8.0
PyQt6-WebEngine               6.7.0
PyQt6-WebEngine-Qt6           6.7.3
PyQt6-WebEngineSubwheel-Qt6   6.7.3
PyQtWebEngine                 5.15.6
PyQtWebEngine-Qt5             5.15.2

sphinxcontrib-qthelp          1.0.6

No PyQt6-QScintilla, but apart from that looks OK...

[Thomas Passin]

I thought PyQt6-QScintilla  is required now (don't know why). There are a few apparent mismatches in versions, like

PyQt6                         6.7.1
PyQt6-Qt6                     6.7.3

I have differences too, only not the same ones as yours.  I don't understand why, but my system has been working normally.

I just created a new venv for Leo and provisioned it using

py -m pip install -r c:\tom\git\leo-editor\requirements.txt

Here's what pip list shows:

PyQt6                         6.7.1
PyQt6-QScintilla              2.14.1

PyQt6-Qt6                     6.7.3
PyQt6_sip                     13.8.0
PyQt6-WebEngine               6.7.0
PyQt6-WebEngine-Qt6           6.7.3
PyQt6-WebEngineSubwheel-Qt6   6.7.3

sphinxcontrib-qthelp          2.0.0

[Thomas Passin]

After a kernel update on my Linux Mint VM just now, I got the same error - no PyQt6-WebEngine.  Upgrading the PyQt6-x packages didn't fix the error.  I installed using requirements.txt into a venv and running in that venv VR3 finds the QWebEngine and runs.

On Monday, November 4, 2024 at 6:51:53 AM UTC-5 jkn wrote:

[jkn]

Hmm - I think I have just done what you suggest above and get the same error as before. ie:

- create a virtual environment

- activate it

- git clone leo...

- cd leo-editor

- python3 -m pip -r requirements.txt

...

- python3 launchleo.py

and (if VR3 is enabled) I get the same error as before (NB: not sure it is exactly what you were reporting):

-

[Thomas Passin]

That seems like just what I did.  You might look at the Qt files in Python's Lib\site-packages in the venv and see if they are symlinked to the files in the main (non-vm) install. I don't know when files in a new VM get symlinked and when they don't.  If they are symlinked then I only have three ideas left:

1. Delete all Qt files yourself and re-install their packages one by one with pip;

2. Downgrade PyQt and the WebEngineView to an earlier version.

If they are not symlinked I would say to do the same but inside the venv's site-package directory.

3. One more possibility would be to delete everything in the venv and re-create it (or make a new one) and to pip-install leo 6.8.1.  This version of Leo may (and probably will) run.  Then just use that venv to run your Leo clone.

Maybe #3 should be the first thing to try.

Oh, yes, can you search for that DLL by name to see if it's actually present on the computer?

[jkn]

Hi Thomas - yes, all good suggestions. I have these and/or similar on my list to check when I have a few minutes. I did look for the .dll yesterday but didn't note down the results

I am not desperate enough to use VR3 to try your option (3), I really just want to have VR3 there in my 'cutting-edge' ;-: Leo to try a few experiments.

I will update in a bit

Thanks, J^n

[Thomas Passin]

Freewin falls back to using a QTextBrowser if a QWebEngineView isn't present.  That only affects the rendered view, not the editor view. The QTextBrowser's rendering is limited compared with the QWebEngineView but that won't really matter for most nodes.

I have removed all the PyQt* files from site-packages and re-installed.  When you remove all those dist files, pip doesn't know that the package had ever been installed.

I wonder if a revised WebEngine package got into PyPi recently and it's accidentally missing the DLL. A downgrade might work in that case.

[jkn]

This is turning into a venv thread rather than anything else, but anyway...

- FWIW I have successfully installed Leo (and VR3 etc.) on two Linux machines via venv.

- on my problematic Windows machine, in a venv, how come all the installed requirements seem to be *not* in the venv? I was expecting them to under <venv>\Lib\site-packages, or similar.

but if I (re-)run

<venv>\leo-editor>  python3 - m pip install -r requirements.txt

then I get a long list of requirements (including PyQt6 ones) already satisfied ... in a location <user>\appdata\local\...

J^n

[Thomas Passin]

I'm no venv expert, that's for sure.  I *think*  that packages installed into a venv can be symlinked from the non-venv installation if they are the same version.  Better try to check that, though.  It sounds like that what's happening in your case.  It didn't seem to in mine.  All a mystery.

If it were my system, I would delete all the Qt* files in the non-venv install, clean out the entire venv, and run pip -r requirements.txt in the venv. As long as you get rid of all the qt* files and folders including the dist* ones, you will get all new files.  If they still didn't work, I would repeat the cleanup and install a lower version of PyQt and the WebEngineView.

[jkn]

Hi Thomas

    yeah, your suggestion is kinda where I am heading. maybe I will try tu use pip in a non-venv environment to tidy things up, instead of just deleting.

My slight concern is whether I have other programs that depend on these. We shall see ... I can think of one but I know that running that in a venv is a known workflow (famous last words), so hopefullt that will not cause me other grief

    J^n

[Thomas Passin]

Don't hesitate to delete all those files.  Or do what I used to do.  Instead of deleting them, move them to some other folder.  You can always copy them back. I used to do that when Leo could use both Qt5 and Qt6. I probably should have used venvs but instead I moved all the Qt6 files out for testing with Qt5, and all the Qt5 files out when testing with Qt6.  Once they are gone, pip doesn't know they were ever installed.  After they are back, they are installed so far as pip is concerned.  As I think back, I remember that when I copied the Qt6 files somewhere, I could get Leo to use them by putting their location on the PYTHONPATH so they would be found first.  I didn't have to physically keep shuttling the files back and forth .

It would only be temporary; copy them back and other programs that use PyQt will be usable.

[jkn]

I've been experimenting and still not getting anywhere. Experiments include:

- using pip uninstall -r requirements.txt, then reinstalling

- clearing out the cache: pip cache purge

- deleting the PyQt files in ...AppData\...

- editing requirements.txt to downgrade eg. PyQt6

nothing has fixed my problem so far ;-(. It looks like there is only v 6.7.0 of PyQy6-Webengine on PyPy BTW.

All very rum ... but these are rum times...

    J^n

[Thomas Passin]

The only things I can think of at this point are to look again to see if that dll file is actually present somewhere, and to try to import the web engine directly in an interpreter session (IOW, not importing from LeoQt) , e.g.,

from PyQt6 import QtWebEngineWidgets

QWebEngineView = QtWebEngineWidgets.QWebEngineView

If the dll file never shows up, maybe an internet search about that specific fact?

[jkn]

Problem found and fixed!

Ironic, given my comment in your GitHub elsewhere issue about 'python' and 'python3'...

your example script worked (ie. gave no errors) both within and without the venv. And then I took a look at LaunchLeo.py and saw the shebang line. And got thinking...

in the venv, "where python3" gives me a location within <username>\Appdata....\python3.exe

but 'where python' gives me a location within the venv, which is what I was expecting.

I have now rerun with just 'python' to re-install things under the venv. And we are up and running!

Also ironically, the shebang line (#! /usr/bin/env python3) is ignored I presume under Windows (who knows, these days). In fact that is probably part of why I was using 'python3' in the first place.

Oh, I was originally looking for that specific error on t'internet (Qt6WebEngineCore.dll not found) without much success.

Thanks a lot for your patient help, Thomas. I have learned a bit about venv in any case ;-)

Regards, jon N

[Thomas Passin]

Good find! You know, I don't even have a "python3" on my Windows path.  If you had used the "py" launcher I think it would have worked right away.  I didn't realize you weren't.  If there have been multiple installations of Python and you don't use "py", lord knows what you will get. In a non-venv command line session, "python" gets me python3.9, and "python3" gets me nothing.

In a venv session here is my sys.path listing running "py"

C:\Tom\venvs>leo_2\Scripts\activate
(leo_2) C:\Tom\venvs>py -V
Python 3.12.3

(leo_2) C:\Tom\venvs>py -c "import sys;print('\n'.join(sys.path))"

C:\Users\tom\AppData\Local\Programs\Python\Python312\python312.zip
C:\Users\tom\AppData\Local\Programs\Python\Python312\DLLs
C:\Users\tom\AppData\Local\Programs\Python\Python312\Lib
C:\Users\tom\AppData\Local\Programs\Python\Python312
C:\Tom\venvs\leo_2
C:\Tom\venvs\leo_2\Lib\site-packages
C:\Tom\venvs\leo_2\Lib\site-packages\win32
C:\Tom\venvs\leo_2\Lib\site-packages\win32\lib
C:\Tom\venvs\leo_2\Lib\site-packages\Pythonwin

Running "python" in the same venv gives me exactly the same listing.  With that sys path, and the Qt packages installed in the venv, they will be found correctly. The same would be true outside of the venv if the Qt packages had been installed with --user.

"py" gets installed by the installer from python.org.  I gather it doesn't when the install is done using the Microsoft store.

I always use "py" to make sure I get the right Python executable. It even knows about my 2.7 install which I need to keep for a legacy program that uses Python 2.7 (actually, it's jython 2.7, but I have use python2.7 to check some programs). With so many versions on my system, I don't let the installer change the Window's path to the various Python scripts, because if I did who knows how the path would end up after next time I install a new version.

[jkn]

(I'll keep this in the same thread for now)

Actually *typing* within the FreeWin window is behaving very strangely ... the cursor is hardly moving, or moving erratically, and my typed text is mostly coming out backwards?

I enter <return> a couple of times and the cursor returns to the top of the screen etc. ... any thoughts?

    Thanks

    J^n

[Thomas Passin]

Thoughts?  Yes indeed.  This nasty behavior showed up some unknown time ago and a fix is now in the latest devel. It was merged yesterday, I think it was. The fix includes an improvement too: typing into the body of the host node will put the cursor in the FW editor where it is in the host, and FW will scroll if needed to put the cursor into view.

The symptom was that the cursor jumped back to the start of the window after every keystroke or two. This happened because typing into the FW editor updates the host, and updating the host updates FW, creating a circular reaction.   I'm not sure when this started happening but it wasn't there when FW was developed.

FW also reacts to the CTRL-s key (when FW is focused), which will save the host's outline. That should be in the docstring but, of course, who reads the docs?

[jkn]

Thanks for the info Thomas - I will update and see where that gets me.

BTW, I have 'save-file' bound to 'Ctrl-W', I hope that that also works ;-)

J^n

[jkn]

git pull and the Freewin cursor behaviour is now correct, thanks!

my 'save-file' key binding does not ;-(

    J^n

[Thomas Passin]

On Monday, November 11, 2024 at 9:59:07 AM UTC-5 jkn wrote:

git pull and the Freewin cursor behaviour is now correct, thanks!

my 'save-file' key binding does not ;-(

It didn't occur to me to use the same binding as the host's editor.  I could look at that.  I'm not sure how but there must be a way.

[jkn]

Hi Thomas

    I would have thought the opposite (use the same binding as the host), but perhaps that is just me. Of course I am being 'perverse' by using non-CUA standard key-bindings; mine match (to a degree) the Brief/CodeWright/CRiSP editor bindings, to match the editor I am most used to.A

I will take a look as well...

Thanks. J^n