Keyboards don't create unicode code points.

You are right, keyval is not always a code point, although often coincidentally the value happens to be the same 😄. But keyval does use at least 25 bits (see cyrillic or armenian in gdkkeysyms.h) so its worse than I thought. Also on some keyboards with "dead" keys GDK maps a multiple key sequences into one key event without IME. And IME still generates a keyevent IIUC with Unicode keyvals.

Most keyboards have fewer than 128 keys.

Not true, some non-asian keyboards have up to 4 values per keycap, see French or probably @eht16's German keyboard. And also which values? As you can see in gdkkeysyms.h keyval can cover a wide range of values. A simple table of all possible keyvalues from keyval to function address is far too big even if state is handled separately.

Thats why I suggest a hash table (or binary tree), key is combined keyval and state from the event and value is the function to call, the number of entries is related to the number of active keybindings, not the number of possible key values and the performance is constant for hash and O(ln(entries)) for tree (say 7 compares of a 64 bit value if 128 keybindings are set). Because keyvals from any one keyboard are likely to be close to sequential the combination and hash of keyval and state needs to ensure that performance does not approach linear worst case if hash is used, probably tree is safer because it doesn't have the bad worst case performance. Don't know which is easier to use/maintain.

Keyboards are a real pain, see also #1368 for another saga.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.