ekr-qt merged into devel

[Edward K. Ream]

The ekr-qt branch contains the last major remaining work for Leo 6.4. The only planned changes will be to leoserver.py, and that file does not affect Leo's core in any way.

The ekr-qt branch contains preliminary support for PyQt6. I do not recommend using Qt6 at this time.

I have merged the ekr-qt branch a day earlier than announced. We may as well all begin testing the code now. I'll fix any remaining problems in a new, much smaller, branch.

Edward

[Félix]

I switched to this new version of devel. started it up, then I opened leopyref in Leo. Saved, it went from 1.5 mb to 138kb. 

Not normal right?

(thought I was going crazy trying to merge devel into my local felix-server branch heheh)

--

Félix

[Edward K. Ream]

On Sun, May 9, 2021 at 9:23 PM Félix <felix...@gmail.com> wrote:

I switched to this new version of devel. started it up, then I opened leopyref in Leo. Saved, it went from 1.5 mb to 138kb. 

Not normal right?

Wow.  I see this too. The smaller version seems to work properly.

There is a script to write LeoPyRef.leo from leoPy.leo. I think maybe this script needs work :-)

Otoh, I would expect my copy of leoPy.leo to be small too, and it isn't. I'll look into this!

Edward

[Edward K. Ream]

On Sunday, May 9, 2021 at 9:23:25 PM UTC-5 Félix wrote:

> I switched to this new version of devel. started it up, then I opened [LeoPyRef.leo] in Leo. Saved, it went from 1.5 mb to 138kb.

I have just created #1926 for this.

Edward

[tbp1...@gmail.com]

I added one space to LeoPyRef.leo then saved it.  I got the same massive size reduction.  Then I looked at the before-after files with kdiff3.  There were big chunks of code missing.  Often they were entire nodes, but I think not always.  So not just a matter of converting spaces to tabs.  After that, each time I closed Leo (where LeoPyRef had been open when I shut down Leo), I was asked if I should  I was asked to save LeoPyRef because it had been changed (not by me!).  If I answered yes, then when I reopened Leo I would get more messages like

initWriteIvars Did not create ../plugins/leo_babel for ../plugins/leo_babel/__init__.py

So no, everything does not necessarily still work.

[Edward K. Ream]

On Monday, May 10, 2021 at 8:50:39 AM UTC-5 tbp1...@gmail.com wrote:

I added one space to LeoPyRef.leo then saved it.  I got the same massive size reduction.  Then I looked at the before-after files with kdiff3.  There were big chunks of code missing.  Often they were entire nodes, but I think not always.  So not just a matter of converting spaces to tabs. 

Thanks for your continued testing.

LeoPyRef.leo is out of sync just now, meaning I changed @clean and @auto nodes to @file in my leoPy.leo, but not LeoPyRef.leo itself (because of the problems re #1926). Things may get worse before they get better :-)

BTW, I am still using Qt 6.0.2 and I am seeing byte hash from time to time.  I just realized that the view-lossage command will tell me what keys Leo/Qt thinks I typed. This command could be improved in several ways. I'll create a new issue for the proposed improvements.

Also, I am pretty sure that Leo's write logic is generally writing too much to the .leo file. I'll create another new issue and a separate branch. The fix might be straightforward, but any change to Leo's write logic is fraught with danger, so no promises when any improvements may become part of Leo.

Edward

[Félix]

I'll wait 'til the devel branch is fixed to make a 'felix-server' branch, and add all the modifications i made to the server at that point. no rush. 

--

Félix

[Edward K. Ream]

On Wed, May 12, 2021 at 3:14 PM Félix <felix...@gmail.com> wrote:

I'll wait 'til the devel branch is fixed to make a 'felix-server' branch, and add all the modifications i made to the server at that point. no rush. 

I just made what should be the last substantial change to devel before releasing Leo 6.4 b1.

Blast away :-)

Edward

[Félix]

So i've pulled the new 'devel' branch... But I'm still seeing problems related to qt in the terminal pane when loading Leo files via LeoBridge. 

They appeared a couple weeks ago, when work on 'qt related stuff' started on the devel branch., I've waited until the qt related work was  considered done to test again/report those. Both errors a caused because QtCore does not exist when having null gui i guess... 

(This is easy to reproduce by simply opening Leo files in leoInteg)

--

Félix

Errors below :

Plugin leo.plugins.nodetags not loaded.

Traceback (most recent call last):

File "/home/felix/leo-editor/leo/core/leoPlugins.py", line 515, in loadOnePluginHelper

__import__(moduleName)

File "/home/felix/leo-editor/leo/plugins/quicksearch.py", line 88, in <module>

from leo.plugins import threadutil

File "/home/felix/leo-editor/leo/plugins/threadutil.py", line 131, in <module>

class Repeater(QtCore.QThread):

AttributeError: 'NoneType' object has no attribute 'QThread'

Plugin leo.plugins.python_terminal not loaded.

Traceback (most recent call last):

File "/home/felix/leo-editor/leo/core/leoPlugins.py", line 515, in loadOnePluginHelper

__import__(moduleName)

File "/home/felix/leo-editor/leo/plugins/stickynotes.py", line 76, in <module>

QTimer = QtCore.QTimer

AttributeError: 'NoneType' object has no attribute 'QTimer'

[Edward K. Ream]

On Sun, May 16, 2021 at 2:39 PM Félix <felix...@gmail.com> wrote:

So i've pulled the new 'devel' branch... But I'm still seeing problems related to qt in the terminal pane when loading Leo files via LeoBridge. 

Thanks for this. I have just created #1942. PR #1943 contains a proposed fix.

Note the extra guards, for Qt itself and for the definition of QTimer.

The new code should fix the immediate problem, but I wonder whether other standard plugins (See the @enabled-plugins node in leoSettings.leo) might also throw exceptions when using leoInteg.

Edward

[Félix]

Thank you - but oh no! -> the bug still remains ! 

It still gives the same errors originating in threadutils.py and stickynotes.py :

Plugin leo.plugins.nodetags not loaded.

Traceback (most recent call last):

File "/home/felix/leo-editor/leo/core/leoPlugins.py", line 515, in loadOnePluginHelper

__import__(moduleName)

File "/home/felix/leo-editor/leo/plugins/quicksearch.py", line 88, in <module>

from leo.plugins import threadutil

File "/home/felix/leo-editor/leo/plugins/threadutil.py", line 131, in <module>

class Repeater(QtCore.QThread):

AttributeError: 'NoneType' object has no attribute 'QThread'

Plugin leo.plugins.python_terminal not loaded.

Traceback (most recent call last):

File "/home/felix/leo-editor/leo/core/leoPlugins.py", line 515, in loadOnePluginHelper

__import__(moduleName)

File "/home/felix/leo-editor/leo/plugins/stickynotes.py", line 281, in <module>

class TextEditSearch(QtWidgets.QWidget):

AttributeError: 'NoneType' object has no attribute 'QWidget'

May I mention that it's not an issue exclusive to leointeg, but rather something that would have happened with any Leo file opened with the standard leoBridge.py if the options to load plugins are enabled. 

I made sure i pulled the changes twice. but looking at the changes, i thought "this wont fix it"... hehe.. the issue is that QtCore does not exist, it's 'noneType' when trying to access its members. So looking at the code i fail to see how its created by what you've added .(you make sure it exist with an 'and' operator, but we already know it's not there to begin with when using leoBridge.py to open a Leo file 'without a gui'.) 

But maybe i've got it all wrong and it's something else entirely ! 

--

Félix

[Edward K. Ream]

On Mon, May 17, 2021 at 6:31 PM Félix <felix...@gmail.com> wrote:

Thank you - but oh no! -> the bug still remains ! 

Oops. I have just created #1946: Ensure that Qt plugins call g.assertUI('qt').

I expect to complete work on this issue later today.

The recent bug happens because I mistakenly removed the call to g.assertUi('qt'). This call raises g.UiTypeException if g.app.gui is not the Qt gui.  The plugins manager catches this exception.

Imo, it's better to use g.assertUI than to create top-level if statements that guard class definitions.

There will be two parts to the fix:

1. Call g.assertUI('qt') in all "real" Qt plugins, as follows:

#
# Fail fast, right after all imports.
g.assertUi('qt')  # May raise g.UiTypeException, caught by the plugins manager.

2. Write a unit test that ensures that all qt plugins raise UiTypeException when using a Null gui.

Edward

[Félix]

Take your time,. i just realized I  had a bug with the setting of the scrolling position , and the selected selection range , which are crucial in the next feature to implement before release of leointeg 1.0 : "search in outline" ctrl+f, f2, f3. etc.. gonna fix this tonight and or tomorrow.  

(other than making leoserver work as much as leobridgeserver  so to replace it completely)

--

Félix 

[Edward K. Ream]

On Tuesday, May 18, 2021 at 9:10:12 AM UTC-5 Edward K. Ream wrote:

Oops. I have just created #1946: Ensure that Qt plugins call g.assertUI('qt').

The work has been merged into devel.

Edward

[Félix]

Thanks!! :D

Imma try this out tonight!