[GH-ISSUE #251] Interoperability with python's keyboard library #212

New issue

Closed

opened 2026-05-05 05:07:18 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 05:07:18 -06:00

Owner

Originally created by @beyarkay on GitHub (Nov 6, 2022).
Original GitHub issue: https://github.com/keycastr/keycastr/issues/251

Hi there!

Just wondering what it would take for this to work with python's keyboard library?

I want to be able to send keystrokes via the library and have keycastr display them. But what is actually happening is that the library is sending the keystrokes correctly but keycaster is displaying just an a for every keystroke, regardless of what I type. Is this something on the libraries side or on keycastr's side?

Originally created by @beyarkay on GitHub (Nov 6, 2022). Original GitHub issue: https://github.com/keycastr/keycastr/issues/251 Hi there! Just wondering what it would take for this to work with [python's `keyboard` library](https://github.com/boppreh/keyboard)? I want to be able to send keystrokes via the library and have keycastr display them. But what is actually happening is that the library is sending the keystrokes correctly but keycaster is displaying just an `a` for every keystroke, regardless of what I type. Is this something on the libraries side or on keycastr's side?

gitea-mirror

2026-05-05 05:07:18 -06:00

closed this issue
added the
compatibility

help wanted
labels

gitea-mirror commented

2026-05-05 05:07:22 -06:00

Author

Owner

@akitchen commented on GitHub (Nov 7, 2022):

Thanks for opening an issue. I would expect this to be supported if the events generated by this library are like any others passed to keycastr in its event tap. It could also be something on keycastr's side, if we're not observing enough input event types in the event tap (see KCKeyboardTap.m)

Do you have a simple example you could share which demonstrates the issue? Pull requests are also welcome if you happen to figure out what adjustments are needed.

@akitchen commented on GitHub (Nov 7, 2022): Thanks for opening an issue. I would expect this to be supported if the events generated by this library are like any others passed to keycastr in its event tap. It could also be something on keycastr's side, if we're not observing enough input event types in the event tap (see KCKeyboardTap.m) Do you have a simple example you could share which demonstrates the issue? Pull requests are also welcome if you happen to figure out what adjustments are needed.

gitea-mirror commented

2026-05-05 05:07:24 -06:00

Author

Owner

@akitchen commented on GitHub (Jun 23, 2023):

Assuming this is a problem with the events generated by the library you mentioned. Please reopen and/or share any interesting learnings.

@akitchen commented on GitHub (Jun 23, 2023): Assuming this is a problem with the events generated by the library you mentioned. Please reopen and/or share any interesting learnings.

gitea-mirror referenced this issue

2026-05-05 05:13:03 -06:00

[PR #212] [MERGED] Minor fix (paragraph 07) #323