4 ms·
I'm the author of the `keyboard`[1] library mentioned in the article. - It reads all events because it's meant to interface with your keyboard directly, for gl
by BoppreH 5y ago
I'm the author of the `keyboard`[1] library mentioned in the article.
- It reads all events because it's meant to interface with your keyboard directly, for global hotkeys, macros, disabling or remaping keys, etc. Interacting with windows and per-application hotkeys are explicitly not a goal of the library at the moment.
- It reads /dev/input because the library was developed to work in as many environments as possible, including headless installations like raspberry pi's that may not have a graphical environment or even a monitor. There's an open change to _try_ to communicate with the X server first and fallback to /dev/input, but event suppression is not working reliably with this yet.
- It could read /dev/input by just being in the `input` group, but then `dumpkeys` doesn't work and you are stuck typing numeric scan codes instead of key names.
Due to a series of unfortunate personal circumstances I've been unable to give the proper maintenance the library requires, but the issues and thank yous have never stopped, and I'm slowly getting back to it again.
---
Little known trick: if you run the library as a standalone module (`python -m keyboard`), it prints a JSON object for each detected event. You can save them to a file and pipe them back (`python -m keyboard < events.txt`) to replay them like a macro.
Little known trick 2: I also created `mouse`[2], the companion library for my second favorite peripheral. It's the same thing, but for mouse events.
[1]: https://github.com/boppreh/keyboard https://github.com/boppreh/keyboard
[2]: https://github.com/boppreh/mouse https://github.com/boppreh/mouse
- RickHull 5y agoFor those interested, I wrote a similar library for Ruby: https://github.com/rickhull/device_input https://github.com/rickhull/device_input
- vanous 5y agoThank you very much for the library. Recently I have been learning touch typing and detecting system wise characters typed per day plus speed and acuracy is on my todo list. I already selected the keyboard module for this after some initial research.
- jorl17 5y agoHi! I've used your library in various projects and am very grateful for it! I figured it'd be worth a shot to ask you this here, since I just caught you: have you considered adding some support for "rehooking"/"restarting" the library, so that callees can restart your library whenever they detect that their environment has changed (e.g. input devices have been (dis)connected, etc)? I've contributed with some info to this issue https://github.com/boppreh/keyboard/issues/264 https://github.com/boppreh/keyboard/issues/264 as to how we're dealing with this in some of our projects. Funnily enough, I didn't know about `python -m keyboard`, and had I known about it, it would definitely have saved me some time! Once again, thank you very much for your hard work!
- BoppreH 5y agoThanks! I've been thinking about how to handle environment changes for a while, and it's pretty hard to reliably detect and respond to them in all supported systems. But I really like the idea of a manual "re-init" method as temporary measure. This should be trivial in Windows, and doable in Linux after some refactoring. Thanks for the idea, I'll take a look tomorrow.