wait_for_click not working

flow-c commented 5 months ago

AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?

Xorg

Has this issue already been reported?

[x] I have searched through the existing issues.

Is this a question rather than an issue?

[X] This is not a question.

What type of issue is this?

Bug

Choose one or more terms that describe this issue:

[X] autokey triggers
[X] autokey-gtk
[X] autokey-qt
[ ] beta
[X] bug
[ ] critical
[ ] development
[ ] documentation
[ ] enhancement
[ ] installation/configuration
[ ] phrase expansion
[X] scripting
[ ] technical debt
[ ] user interface

Other terms that describe this issue if not provided above:

No response

Which Linux distribution did you use?

Linux 6.10.6-arch1-1 x86_64

Which AutoKey GUI did you use?

Both

Which AutoKey version did you use?

0.96.0-6

How did you install AutoKey?

From the Arch User Repository (AUR)

Can you briefly describe the issue?

mouse.wait_for_click(1, timeOut=None) does not trigger when left mouse button is clicked.

Can the issue be reproduced?

Always

What are the steps to reproduce the issue?

Run the following TEST script by any means (Tools→Run current script, hotkey, etc.):
```
mouse.wait_for_click(1,  timeOut=None)
dialog.info_dialog("All good")
```
Click the left mouse button

What should have happened?

A dialog should open and display "All good".

What actually happened?

Nothing

Do you have screenshots?

No response

Can you provide the output of the AutoKey command?

2024-06-06 21:37:08,320 INFO - autokey.gtkapp - Initialising application
2024-06-06 21:37:08,327 INFO - autokey.gtkapp - Initialise global hotkeys
2024-06-06 21:37:08,327 INFO - autokey.configmanager.configmanager - Loading config from existing file: /home/flow-c/.config/autokey/autokey.json
2024-06-06 21:37:08,327 INFO - autokey.configmanager.version_upgrading - Checking if upgrade is needed from version 0.96.0
2024-06-06 21:37:08,329 INFO - autokey.configmanager.configmanager - Configuration changed - rebuilding in-memory structures
2024-06-06 21:37:08,329 INFO - autokey.configmanager.configmanager - Successfully loaded configuration
2024-06-06 21:37:08,330 INFO - autokey.service - Starting service
2024-06-06 21:37:08,580 INFO - autokey.iomediator.iomediator - Created IoMediator instance, current interface is: <XRecordInterface(XInterface-thread, initial daemon)>
2024-06-06 21:37:08,600 INFO - autokey.interface - XRecord interface thread starting
2024-06-06 21:37:08,602 INFO - autokey.service - Service now marked as running
2024-06-06 21:37:08,687 INFO - autokey.gtkapp - Entering main()
2024-06-06 21:37:12,044 INFO - autokey.service - Matched Script "TEST" with hotkey and prompt=False

Anything else?

Python 3.12.5

josephj11 commented 4 months ago

TL;DR: Why not just pass it a large value for timeout and see if that works?

The API documentation says that timeout has to be a floating point number. It does not say what does or should happen if you pass it as None.

I found

def wait(self):
        return self.event.wait(self.time_out)

in waiter.py, That goes into the threading module which is part of Python. I looked briefly, but didn't see what it would do when passed None.

Can you just give it a large value instead? (It will throw an overflow exception if it's too big.)

Since AutoKey is threaded, it can do other things while that script is running, but leaving things running indefinitely, especially for a long time (several minutes or more) is a largely untested domain and there may be monsters lurking.

flow-c commented 4 months ago

Sorry for leading you onto the wrong track. The delay is actually irrelevant here. I just chose None to illustrate the problem in its most extreme case. (I think I checked the source code to verify that None is valid, albeit undocumented).

The problem is that the click event never triggers. For example with

mouse.wait_for_click(1,  timeOut=10)
dialog.info_dialog("No clicks to be seen here. Please move on!")

the dialog is displayed after the 10-second delay no matter if or how many times the mouse was clicked in between.

Togtja commented 2 months ago

Experiencing same problem on Ubuntu 22.04 Other mouse event work it is just wait_for_click

josephj11 commented 2 months ago

The following modified version of the script confirms this bug. It reports that slightly over 10 second elapse and no click was detected because the duration would be less if it was detected. It always runs the else block even if mouse buttons are pressed within the delay time. It does display the info dialog correctly. I tried setting the button to "1" which also did the same thing as setting it to 1.

The time math is necessary because mouse.wait_for_click has no retcode to test. (There's an enhancement request to add one to it.)

delay = 10
t0 = time.time()
mouse.wait_for_click(1,  timeOut=delay)
t1 = time.time()

duration = t1 - t0
if duration < delay:
  msg = "Got a click after " + str(duration) + " seconds"
  dialog.info_dialog(title="Click", message=msg)
else:
  msg = "No clicks after " + str(duration) + " seconds"
  dialog.info_dialog(title="Click", message=msg)

josephj11 commented 2 months ago

Claude.ai suggests this code. It just needs a timeout added to the listener if it's compatible with AutoKey. I didn't try it. The print()s won't usually do anything in AutoKey because there's no stdout in the GUI.

from pynput import mouse

def on_click(x, y, button, pressed):
    if pressed:
        print(f'Mouse clicked at ({x}, {y}) with {button}')
        return False  # Stop listener

# Create a listener
with mouse.Listener(on_click=on_click) as listener:
    listener.join()

print("Mouse click detected. Exiting...")

Elliria commented 2 months ago

For the record, I do not have this issue in Kubuntu 22.04 LTS when using AutoKey 0.95.10, so something changed in the mouse.wait_for_click() code between the two releases. A search of the pull requests for wait_for_click turns up this PR and this is the changed code.

Examples of `mouse.wait_for_click()` that work for me in AutoKey 0.95.10:

This example waits for the five-second timer to run out before displaying the dialog or waits for a left-click before displaying the dialog:

mouse.wait_for_click(1, timeOut=5.0)
dialog.info_dialog("hello world")

This example waits for a left-click before displaying the dialog:

mouse.wait_for_click(1,  timeOut=None)
dialog.info_dialog("hello world")

This example waits for a left-click before displaying the dialog:

mouse.wait_for_click(1,  timeOut=0)
dialog.info_dialog("hello world")

Elliria commented 2 months ago

From looking at the code, my guess is that since the w.wait() method was moved into the return, it no longer actively waits while the wait_for_click() function is running, but is only activated upon the return of the wait_for_click function, which happens when the timer runs out.

josephj11 commented 2 months ago

@Elliria Which version of Python3 are you using python3 --version?

Good catch, but...

That change was made to the develop branch and I verified that it is not in the code I am running (0.96.0 beta 10) which, AFAIK, is the same as 0.96.0.

Research:

The code rapidly moves into the threading.py module where I lost track of what was going on. AFAIK, that's part of core Python (upstream from AutoKey) and may have changed in Python 3.10 and newer. I think 3.12 or 3.13 is current, but our GitHub actions haven't been updated for those yet.

I am running Python 3.12.

And: Venice.ai reports

when was the threading.py module (and the things it depends upon) last updated since Python 3.7

Venice

3.80 sec

•

Nous Theta 8B (Fastest)

The threading.py module in Python was last updated as part of the 3.11 release on October 24, 2021 ¹. The underlying CPython implementation details may have been updated independently for each minor version since then. For specific changes and updates to threading, you can refer to the official Python documentation or the Changelog provided by the Python Development Team.

References: ² Python Official Documentation: Lib/threading.py ³ Python 3.11 Release Notes: https://docs.python.org/3/whatsnew/3.11.html

threading On Unix, if the sem_clockwait() function is available in the C library (glibc 2.30 and newer), the threading.Lock.acquire() method now uses the monotonic clock (time.CLOCK_MONOTONIC) for the timeout, rather than using the system clock (time.CLOCK_REALTIME), to not be affected by system clock changes. (Contributed by Victor Stinner in bpo-41710.)

This was done 10/24/2021, two months before the AutoKey PR (12/05/2021) and I don't know what version the PR was tested against.

IDK if any of our actions apply to the develop branch. I didn't immediately see evidence of any being run in the merge.

Togtja commented 2 months ago

Just to give more info on my Ubuntu 22 setup autokey versions

$ ll autokey-*
-rw-rw-r-- 1 togtja togtja 102012 aug.  29 09:13 autokey-common_0.96.0_all.deb
-rw-rw-r-- 1 togtja togtja  51664 aug.  29 09:20 autokey-gtk_0.96.0_all.deb
-rw-rw-r-- 1 togtja togtja 142448 aug.  29 09:13 autokey-qt_0.96.0_all.deb

$ python3 --version
Python 3.10.12

If you need more details let me know

Elliria commented 2 months ago

I'm using Python 3.10.12. In looking at what's new in Python, I got the impression that they updated the timeout, but that's working fine. The issue is with the clicks that aren't being recognized. It's possible that the code in that pull-request fixes the issue. Have any of you tried cloning the beta and testing it out on a system that uses a more recent Python version?

flow-c commented 2 months ago

I've just tried the develop branch (commit e0a2753b) and the problem is fixed there! Mouse clicks are recognised as expected – albeit with a delay of several seconds.

Is it worth me bisecting the branch to identify the commit that fixes the issue, or is develop going to be merged into master soon anyway?

josephj11 commented 2 months ago

@flow-c Thanks for making the effort to check that. Currently, we have no active developers, so we're on our own. If you want to bisect, etc., please let us know the results. Also, there are issues with synchronizing main and develop because both branches are ahead and behind each other for a number of commits and I'm not clear on what it will take to unravel that.

Since it works in develop, can we close this as complete? You can still add notes to it from your research...

Elliria commented 2 months ago

Heads up that that's the Update documentation to work with sphinx better commit that changes documentation. It's one of several changes that are being made in @sebastiansam55's pull request #844, is still in the draft stage, and is part (or all) of the effort to switch to Wayland.

josephj11 commented 2 months ago

@Elliria If we want to use this now, then it will have to be bisected out and isolated from the Wayland stuff. Separate issues should be separate commits and (usually) separate merges so we can cherry pick as necessary and only revert problem code and not large chunks of unrelated code should problems occur...

Elliria commented 1 month ago

There doesn't seem to really be a point to bisecting it, though, since the project isn't in a position to put out another release. Perhaps it would be better to let @sebastiansam55 finish that PR and when/if the project becomes capable of putting out new releases, it will be part of the final merge that creates the new release.

joaociocca commented 1 month ago

so, there won't be a fix for this before migrating to wayland... that's sad for nvidia users like me =(

flow-c commented 1 month ago

Would we be able to release a patched version 0.96.1 at least?

As far as I can tell the offending commit is 5c0a130d43f7c897bab45c83f7972f8b368765cb. Instead of going through its original list of listeners, IoMediator makes a copy first, then runs handle_keypress and handle_mouseclick on the copied versions. There are also some related changes to the Keyboard class that I haven't yet wrapped my head around, but I doesn't seem too difficult to unwind.

josephj11 commented 1 month ago

I have no objections to a minimal 0.96.1 release. I want my pet issue included that issues a warning or error if it detects Wayland running. Problem is we currently have no active devs to build or release anything. Also, there needs to be a discussion of what, if anything, else should be included. We had problems with GitHub actions (which I believe are fixed) which made a number of prominent distros fail to include 0.96.0 in their repos. We should verify that won't be a problem for 0.96.1.Sent from my Galaxy -------- Original message --------From: flow-c @.> Date: 9/6/24 8:29 AM (GMT-05:00) To: autokey/autokey @.> Cc: Joe @.>, Comment @.> Subject: Re: [autokey/autokey] wait_for_click not working (Issue #945) Would we be able to release a patched version 0.96.1 at least? As far as I can tell the offending commit is 5c0a130. Instead of going through its original list of listeners, IoMediator makes a copy first, then runs handle_keypress and handle_mouseclick on the copied versions. There are also some related changes to the Keyboard class that I haven't yet wrapped my head around, but I doesn't seem too difficult to unwind.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

josephj11 commented 1 month ago

Haven't heard from Sam in quite a few months. He was still alive on GitHub last I checked. No idea if he's still involved with AutoKey.Sent from my Galaxy -------- Original message --------From: Elliria @.> Date: 9/5/24 3:22 PM (GMT-05:00) To: autokey/autokey @.> Cc: Joe @.>, Comment @.> Subject: Re: [autokey/autokey] wait_for_click not working (Issue #945) There doesn't seem to really be a point to bisecting it, though, since the project isn't in a position to put out another release. Perhaps it would be better to let @sebastiansam55 finish that PR and when/if the project becomes capable of putting out new releases, it will be part of the final merge that creates the new release.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

josephj11 commented 1 month ago

We're not saying that. I'm open to a 0.96.1 maintenance release if we can find any devs to make that happen.Sent from my Galaxy -------- Original message --------From: João Ciocca @.> Date: 9/5/24 4:45 PM (GMT-05:00) To: autokey/autokey @.> Cc: Joe @.>, Comment @.> Subject: Re: [autokey/autokey] wait_for_click not working (Issue #945) so, there won't be a fix for this before migrating to wayland... that's sad for nvidia users like me =(

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

joaociocca commented 1 month ago

We're not saying that. I'm open to a 0.96.1 maintenance release if we can find any devs to make that happen.

I have absolutely no idea how to help with that :rofl: but if anyone's willing to give some pointers, I should be getting PTO in a month, and could help

josephj11 commented 1 month ago

Thanks. Keep in touch on Gitter so you can see if anything starts happening that you want to help with.Sent from my Galaxy -------- Original message --------From: João Ciocca @.> Date: 9/6/24 1:09 PM (GMT-05:00) To: autokey/autokey @.> Cc: Joe @.>, Comment @.> Subject: Re: [autokey/autokey] wait_for_click not working (Issue #945)

We're not saying that. I'm open to a 0.96.1 maintenance release if we can find any devs to make that happen.

I have absolutely no idea how to help with that 🤣 but if anyone's willing to give some pointers, I should be getting PTO in a month, and could help

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

autokey / autokey