Tags: anko/xkbcat
Tags
Use group 0 if current group contains no keysym Fixes #5, perhaps fully this time. It seems non-zero keysym groups work such that if no keysym is defined in it, the default 0 group's keysym is assumed. In other words, common keys that would otherwise just be duplicated in the group's definition, such as Return, Backspace, Delete, Shift, Space, or the numpad keys, just have no symbol mapped to them at all in the group (XkbKeycodeToKeysym returns NoSymbol). In such cases, it seems the receiving program is expected to just fall back to group 0 and read the keysym from there instead. This is about XKeycodeToKeysym, but XkbKeycodeToKeysym which we're using (note the different prefix) seems to function the same: https://stackoverflow.com/questions/54483276/xkeysymtokeycode-and-keyboard-layout This seems to be correct with the keyboard layouts I've tested. - - - Other Xlib users have replaced XKeycodeToKeysym with XGetKeyboardMapping instead. These patches to that effect imply XKeycodeToKeysym is deprecated: - https://lists.freedesktop.org/archives/piglit/2012-January/001795.html - ArcticaProject/nx-libs@c79f2d2 XkbKeycodeToKeysym is not deprecated though, and seems a much better fit here than doing heap allocations in a loop, so I'll go with it.
Support switching keyboard layouts As noted in issue #5, xkbcat would previously not react at all to keyboard layout changes; it would continue to print keysyms according to the first keyboard layout X was started with. Keyboard keysym group changes (i.e. keyboard layout changes) are listened to as separate events, so if you only use 1 layout, this causes no performance overhead. Closes #5. Thanks to @unxed for very helpful research.
PreviousNext