Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting higher mouse button numbers #39

Closed
Ravirael opened this issue Aug 1, 2017 · 3 comments
Closed

Supporting higher mouse button numbers #39

Ravirael opened this issue Aug 1, 2017 · 3 comments

Comments

@Ravirael
Copy link

Ravirael commented Aug 1, 2017

Mouse buttons with number higher than 9 are indistinguishable from each other on XOrg implementaion of mouse Listener. That's of course caused by enum Button which doesn't support buttons higher than 9 and thus listener reports Button.unknown.

I cannot see a reason for such limitation. Of course there is a workaround but I believe this should be changed anyway.

Workaround to detect button with number higher than 9 in listener:

from pynput import mouse

def number_aware_button(number):
    try:
        button = mouse.Button(number)
    except ValueError:
        button = mouse.Button.unknown
    button.button_number = number
    return button

def on_click(x, y, button, pressed):
    print('Button {0} {1} {2}'.format(
        button,
        button.button_number,
        'pressed' if pressed else 'released')
        )

with mouse.Listener(on_click=on_click) as listener:
    listener._button = number_aware_button
    listener.join()
@moses-palmer
Copy link
Owner

Thank you for your report.

The reason that buttons are represented as enums is because of the simplicity of consumption: a simple if button == Button.left is enough to check which button was pressed.

At the same time, I realise that the library breaking for arbitrary buttons is... well, bad. Unfortunately your proposed solution does not work; it will modify Button.unknown.button_number every time an unknown button is encountered, leading to strange behaviour in multi threaded code.

At the moment, the best solution I can think of is extending 5bddf97 - Added values for button 8 and 9 for Xorg to include even more buttons. While this solution may seem less elegant, there does exist some limitation on the possible number of buttons, so it might not be as bad as it seems.

Another possibility is to create a different, non-enum, class for buttons greater than Button.button9. What do you think? I have never used a mouse with more than seven buttons, including the scroll wheel, so I might not be the best judge ;-)

@Ravirael
Copy link
Author

Ravirael commented Aug 7, 2017

@moses-palmer My mouse (Logitech MX Performance) has 4 additional buttons numbered as 8, 9, 10, 13. I guess it is some kind of standard numbering scheme. Buttons 8 i 9 work as backward/forward in web browser. The 13 is a "zoom" button and indeed combined with scroll wheel enables zooming in web browser.

Extending the enum wouId certainly work. I don't know what is the limit (maybe 255 if the number is encoded on one byte?) but it's not 9. I think it is not very difficult to create enum dynamically in python without having to list every possible value so you can easily go up to 255 with one loop.

I think that using another class instead of Button.unknown is also an acceptable solution, although it may be a bit counterintuitive that the type of button can be either enum or something else.

@moses-palmer
Copy link
Owner

I added buttons up to 30 in pynput 1.3.7. Create a new bug report when you get a new mouse :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants