Supporting higher mouse button numbers about pynput HOT 3 CLOSED

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 ;-)

from pynput.

@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.

from pynput.

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

from pynput.