New Way To Expand/Contract Leo Trees

[Thomas Passin]

Just merged into the devel branch is a new way to expand or contract nodes using the mouse.  When you hold the CTRL key and move the mouse over a node, it will expand.  When you hold down the SHIFT key instead, the node will contract.

In practice, this means that you can just wave the mouse over the tree in the region you are interested in, and those nodes will expand or contract.  This is much easier than trying to click on the little arrow icons.  It can also open a contiguous region of nearby nodes, which is often very useful.  Otherwise you would have to click on one arrow after another (or use the equivalent keyboard shortcuts time after time).

I invented this technique many years ago for an in-browser javascript app, and I've always been happy with it. Yesterday I realized that it could easily be implemented in Leo.

[Edward K. Ream]

On Sat, Mar 25, 2023 at 6:21 AM Thomas Passin <tbp1...@gmail.com> wrote:

Just merged into the devel branch is a new way to expand or contract nodes using the mouse.  When you hold the CTRL key and move the mouse over a node, it will expand.  When you hold down the SHIFT key instead, the node will contract.

Thanks for this improvement. It's a creative UI design, implemented with remarkably little code.

Edward

[Edward K. Ream]

On Saturday, March 25, 2023 at 6:21:56 AM UTC-5 tbp1...@gmail.com wrote:

Just merged into the devel branch is a new way to expand or contract nodes using the mouse.  When you hold the CTRL key and move the mouse over a node, it will expand.  When you hold down the SHIFT key instead, the node will contract.

I just lost 30+ minutes of work due to a hard crash.

I don't know what caused the crash, but I am going to disable the new UI code as a precaution.

Edward

[Thomas Passin]

I think it's a crash from Qt, but not from this new UI code.  That's because I have been getting hard crashes for weeks at least.  I did not used to get them, so I'm thinking it's something about a particular version of Qt, or a Windows update (In fact, I had an update recently).

I think it's Qt because I get error events in the Windows Event Viewer, and they usually give an error code that indicates a buffer overrun in Qt (I'm also sometimes getting a new crash when I try to open Freewin, but that's something different - a cross-thread deadlock).

Here is an example of an error report I've been getting:

Faulting application name: python.exe, version: 3.10.9150.1013, time stamp: 0x638fa05d
Faulting module name: Qt6Core.dll, version: 6.4.1.0, time stamp: 0x636a3508
Exception code: 0xc0000409
Fault offset: 0x0000000000011918
Faulting process id: 0x460c
Faulting application start time: 0x01d955e06c2acb33
Faulting application path: C:\Users\tom\AppData\Local\Programs\Python\Python310\python.exe
Faulting module path: C:\Users\tom\AppData\Local\Programs\Python\Python310\lib\site-packages\PyQt6\Qt6\bin\Qt6Core.dll
Report Id: 29c7eb9c-6cde-46f3-98eb-a05b5e44f4dc
Faulting package full name:
Faulting package-relative application ID:

 

The exception code has been reported as: 

EXCEPTION_CODE : 0xc0000409 (“The system detected an overrun of a stack-based buffer in this application”)

The other exception code I get is 0xc0000005, which is means "access denied".  That usually means an attempt to access memory that the app is not allowed to (e.g., a buffer overrun), but presumably in the heap.

To see these events in the Event Viewer:

1. Open the Event Viewer as an administrator;

2. In the viewer, select Windows Logs/Application;

3. In the right-hand panel, click on "Filter Current Log";

4. In the dialog that comes up, check "Error", then in the edit line labeled "Includes/Excludes Event IDs", type 1000. 

5. Click on OK.

BTW, I save *all the time*.  Am I thinking instead of typing?  CTRL-S. I could never lose 30 minutes of work.  Old habits die hard, I guess, but it's an ass-saver.

[Edward K. Ream]

On Sun, Mar 26, 2023 at 8:06 AM Thomas Passin <tbp1...@gmail.com> wrote:

I think it's a crash from Qt, but not from this new UI code.  That's because I have been getting hard crashes for weeks at least.  I did not used to get them, so I'm thinking it's something about a particular version of Qt, or a Windows update (In fact, I had an update recently).

...

Here is an example of an error report I've been getting:

Thanks for the report. Have you reported these crashes to Qt?

To see these events in the Event Viewer:

1. Open the Event Viewer as an administrator;

2. In the viewer, select Windows Logs/Application;

3. In the right-hand panel, click on "Filter Current Log";

4. In the dialog that comes up, check "Error", then in the edit line labeled "Includes/Excludes Event IDs", type 1000. 

5. Click on OK.

Thanks. I haven't encountered hard crashes in so long that I had forgotten how to do this.

Edward

[Edward K. Ream]

On Sun, Mar 26, 2023 at 8:06 AM Thomas Passin <tbp1...@gmail.com> wrote:

I think it's a crash from Qt, but not from this new UI code. 

Imo the new UI code isn't off the hook yet. Qt should never crash, but Leo's tree drawing code has crashed Qt many times in the past.

Edward

[Thomas Passin]

I just now got repeated crashes when trying to do a particular operation - it started happening every time.  My script goes out to the internet and tries to download a file, which in this case was a .pdf file.  I commented out the new mouse gesture code, and still got the same crash.  It's always the same exception code, and it's always the code for "access denied", coming from Qt6.  So it's something about Qt, but in this case it's not the new mouse code.  It is a reproduceable  exception that seems to happen specifically for this one URL.

It happens that this exception has a different code than the ones I got earlier, so something else could still be going on.  Better to play it safe, I suppose.  I'll keep working on this and see if I get any more crashes with the code in or out.

[Edward K. Ream]

On Sun, Mar 26, 2023 at 9:43 AM Thomas Passin <tbp1...@gmail.com> wrote:

I just now got repeated crashes when trying to do a particular operation - it started happening every time.  My script goes out to the internet and tries to download a file, which in this case was a .pdf file.  I commented out the new mouse gesture code, and still got the same crash.  It's always the same exception code, and it's always the code for "access denied", coming from Qt6.  So it's something about Qt, but in this case it's not the new mouse code.  It is a reproduceable  exception that seems to happen specifically for this one URL.

It happens that this exception has a different code than the ones I got earlier, so something else could still be going on.  Better to play it safe, I suppose.  I'll keep working on this and see if I get any more crashes with the code in or out.

Thanks for your continued testing. This sounds like progress.

I just switched to Qt6--I had been using Qt5.  I'll let you know if I get any crashes.

Edward

[Thomas Passin]

I've been using Qt PyQt version 6.4.1. 

[Edward K. Ream]

On Sun, Mar 26, 2023 at 10:07 AM Thomas Passin <tbp1...@gmail.com> wrote:

> I've been using Qt PyQt version 6.4.1.

I am using 6.4.3.

Edward

[Mike Hodson]

On Sun, Mar 26, 2023 at 6:11 AM Edward K. Ream <edre...@gmail.com> wrote:

I just lost 30+ minutes of work due to a hard crash.

I think this is a problem with the internal design of Leo not consistently saving a state to disk that can be recovered later, like many[most?] other text editors today. 

I also think this non-always-stateful-autosave is why I stopped using leo.. The 'autosave' script caused UI redrawing every single time it ran, which I had run every few seconds to get the granularity of what I expect to be saved, and it caused a lot of visual hassle to deal with, sometimes the keystrokes im typing do not go where they should/get missed because the UI is redrawing, and thus I feel the internal design is not decoupled from the UI enough.

My $0.02 adjusted for inflation (closer to $0)

Mike

 

[Thomas Passin]

I agree that making Leo do autosave smoothly every few seconds or at least often could be hard.  I certainly wouldn't want it to freeze for a short (or sometimes longer) time while it saved. 

OTOH, I'm never sure I really want autosave. I've had plenty of times where I don't save on purpose since I suspect I might want to revert what I'm trying out.  When that's not the case, It's easy enough to save, which I tend to do by reflex, probably left over from Windows 95 and Windows 2000 days (remember them?).

[Mike Hodson]

On Sun, Mar 26, 2023 at 12:04 PM Thomas Passin <tbp1...@gmail.com> wrote:

I agree that making Leo do autosave smoothly every few seconds or at least often could be hard.  I certainly wouldn't want it to freeze for a short (or sometimes longer) time while it saved. 

OTOH, I'm never sure I really want autosave. I've had plenty of times where I don't save on purpose since I suspect I might want to revert what I'm trying out.  When that's not the case, It's easy enough to save, which I tend to do by reflex, probably left over from Windows 95 and Windows 2000 days (remember them?).

I tend to appreciate an editor that has 2 "states".  One being the current running content of any editor window/tab/pane/etc that can consistently be saved, with undo history, to disk, as things are typed.  The other, being the state of the file itself.

I want an editor to remember everything I've just typed since [the opening of the editor if nothing is saved / the last save] in that 'constant undo-history-saved running state' and then when I want to write out to a file, it then moves the current state into the saved file.

Kate/kwrite almost dues this, if you save a file first.

Sublimetext actually does as I describe, but does not work the same way Leo can, and extending it is far different than what Leo can do (as well as is closed source/paid)

I haven't used many other editors, since having this functionality is somewhat required since I've experienced 25+ years of random hard _machine_ freezes, not just editor freezes, and I need to recover what I've typed.  I stopped using SGI XFS because it would not reliably flush its caches out to disk and I'd hard crash, and a file I *knew I had just saved* was gone. Ugh. 

Now its root-on-ZFS and I attempt to use things that save intermediate state so that an app or system crash won't delete more than a minute or so of work.

Mike

Mike

[lewis]

I added @bool use-mouse-expand-gestures - True   to myLeoSetttings.leo but the mouse-over expand/contract is still disabled. Does the setting need to be changed in qt_tree.py ?

[Edward K. Ream]

On Mon, Mar 27, 2023 at 2:00 AM lewis <lewi...@fastmail.com.au> wrote:

I added @bool use-mouse-expand-gestures - True   to myLeoSetttings.leo but the mouse-over expand/contract is still disabled. Does the setting need to be changed in qt_tree.py ?

I assume you use '=' instead of '-' in the setting -)

It looks like Thomas forgot to enable the new code in qtree.initAfterLoad.

PR #3221 (merged into devel) re-enables the new code and adds the setting (default False) to leoSettings.leo.

Edward

[Edward K. Ream]

On Sunday, March 26, 2023 at 12:37:52 PM UTC-5 mys...@gmail.com wrote:

The 'autosave' script caused UI redrawing every single time it ran, which I had run every few seconds.

Issue #3223 suggests that the mod_scripting plugin not affect the UI.

Edward

[lewis]

Yes I did use '='  in the setting.

The mouse-over is working fine. I haven't had any crashes using the gesture on Win10.

[Edward K. Ream]

On Mon, Mar 27, 2023 at 4:24 AM lewis <lewi...@fastmail.com.au> wrote:

Yes I did use '='  in the setting.

The mouse-over is working fine. I haven't had any crashes using the gesture on Win10.

Thanks for the update.

Edward

[Thomas Passin]

I did forget to uncomment the line, but I *thought* I had caught that with a later PR.  Sorry!

[Edward K. Ream]

On Sunday, March 26, 2023 at 12:37:52 PM UTC-5 mys...@gmail.com wrote:

On Sun, Mar 26, 2023 at 6:11 AM Edward K. Ream <edre...@gmail.com> wrote:

I just lost 30+ minutes of work due to a hard crash.

I think this is a problem with the internal design of Leo not consistently saving a state to disk that can be recovered later.

The revised mod_autosave plugin addresses this concern by writing to .bak files. The plugin should no longer affect normally editing in any way--the plugin should never change any part of Leo's UI, including the changed indicator in the headline and the outline's changed status. As a result, the plugin will write to the .bak file until the user explicitly saves the outline.

Anything else keeping you from using Leo :-)

Edward