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? On Monday, November 11, 2024 at 4:49:40 AM UTC-5 jkn wrote: > (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 > > > > On Wednesday, November 6, 2024 at 9:11:16 PM UTC [email protected] wrote: > >> 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. >> >> >> On Wednesday, November 6, 2024 at 3:35:08 PM UTC-5 jkn wrote: >> >>> 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 >>> >>> On Wednesday, November 6, 2024 at 7:39:29 PM UTC [email protected] >>> wrote: >>> >>>> 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? >>>> >>>> >>>> On Wednesday, November 6, 2024 at 1:38:20 PM UTC-5 jkn wrote: >>>> >>>> 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 >>>> >>>> -- 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 visit https://groups.google.com/d/msgid/leo-editor/2511d44a-9340-4064-8a9c-2a9187f5fe1cn%40googlegroups.com.
