Undo action on second trigger like in GNOME

[cz-dev-ge]

Is your feature request related to a problem? Please describe.
I always try to bump the corner a second time to close the overview again. That's how it works under GNOME. Would be great to have it as an option.

Describe the solution you'd like
Add a setting "use hot corner as toggle" to enable my command on the first bump and disable it on the second.

Additional context
Try how it works in GNOME. You get used to it very fast and it's frustrating if it is not available on another system.

[vhanla]

They undo actions, most of them. I guess All Windows might not "undo" on Windows 11, I have to double check that, I guess it has to do with different class names on task view. I'm on Windows 10 now.

[Crilum]

Any progress on this?? I would love to be able to undo opening the overview. :)

EDIT:
I think I found where the issue is...

winxcorners/Main.pas

Line 324 in 492c0e1

if GetForegroundWindow = FindWindow('MultitaskingViewFrame', nil) then

From ChatGPT regarding the Task View window class name:

On Windows 11, XamlExplorerHostIslandWindow typically serves as the window class for Task View. This replaces MultitaskingViewFrame from Windows 10.

I would submit a PR, but I have no experience with Pascal, and I don't currently have access to Delphi to test any changes I make...

[vhanla]

Any progress on this?? I would love to be able to undo opening the overview. :)

EDIT: I think I found where the issue is...

winxcorners/Main.pas

Line 324 in 492c0e1

if GetForegroundWindow = FindWindow('MultitaskingViewFrame', nil) then

From ChatGPT regarding the Task View window class name:

On Windows 11, XamlExplorerHostIslandWindow typically serves as the window class for Task View. This replaces MultitaskingViewFrame from Windows 10.

I would submit a PR, but I have no experience with Pascal, and I don't currently have access to Delphi to test any changes I make...

Indeed, it is already commented out there in the code. MultitaskingViewFrame was for Ctrl+Alt+Tab window in Windows 10 (I don't know if it is the same for Windows 11), but TaskView in Windows 10 is of classname Windows.UI.Core.CoreWindow as it is also commented out there, however, there seems to be a lot of other windows with that classname, and the title depends on the system language.
So, I might use RegisterWindowMessage('TaskbarCreated') to check on every explorer.exe restart (which is the parent process for the Task View with classname Windows.UI.Core.CoreWindow) and there are two as it seems with the same title name, apart from the other ones not belonging to the explorer.exe which are for instance the Start Menu, Search, etc. as shown in this picture:

So, I guess, if there are more than one Windows.UI.Core.CoreWindow windows instances with different titlebar names, a settings value might be used to let the user pick the right one, in order to dig for executable name from a window might be resource intensive on each mouse movement, instead of just matching the FindWindow variables currently used. 😅

And about Windows 11, I haven't used it for a while, and it might have the same issues.