Conversation
- Keys mapped with "mapsym" are handled before keys mapped with just "map". This is convenient, since default keys are mapped with "map" and thus would need to be set to "no_op" using the GLFW-name before being able to map them via sym - Added option of using "+" by escaping it as "plus"
|
Some comments:
Now if you really want to do this, here are some thoughts:
|
|
Turns out libxkb has a function we can use to get sym codes from names, https://xkbcommon.org/doc/current/group__keysyms.html#gad6b3273c0a82876bba5bd59958358fbe that should make this significantly easier to implement. Now you just need to wrap this as an API in glfw3native.h for the X11 and wayland backends |
…ted by GLFW Useful to bind keys such as the play/pause or volume buttons. Also can be used to bind non-ascii keys on international keyboards. Fixes kovidgoyal#665
This pull-request adds the option to add keyboard shortcuts based on symbols instead of GLFW-keys.
The necessity of using GLFW-keys is quite annoying to any user of non-English keyboards, since some keys can simply not be mapped (see #643).
In order to not break with the current mappings, it adds a new identifier to the config:
mapsym.e.g.:
mapsym kitty_mod+* change_font_size all +2.0can be used on a german keyboard to map the "+"-key (which becomes a "*", when pressed together with shift). It is important to always specify the symbol with modifiers applied, (i.e. mapping shift+x will not work, since there is usually no way to get a lower-case x at the same time as shift -> use shift+X) when mapping.
Technical details:
Keybindings are stored and processed in python, just like ordinary key-presses.
In C, there is the array
needs_special_sym_handling, which takes the utf-8-encoded symbol as the index mangled with the mod-keys for early decisions whether a mapping should be sent to python (much like theneeds_special_handling-array). Note that this is only an early detection, whether the pressed keys might need special treatment, since the actual decision, whether to treat it in a special manner is taken in Python. For that reason, it is not necessary for theneeds_special_sym_handling-table to uniquely map each symbol to a different entry and thus, it does not have to be big enough to store every symbol/mod-combination.The symbols that are used are are given by
xkb_state_key_get_utf8. There is one downside to that function: When using Ctrl+Shift, it does not generate any symbols. My proposal here is to simply ignore the Ctrl while resolving the symbol, if Shift is pressed, as well.The current implementation otherwise explicitly does not generate the symbol-text, if either Ctrl, Alt, or Super are pressed. For this purpose, however, I changed that behaviour, which is not really necessary in my opinion. (i.e. formerly pressing Ctrl+Shift+Z would simply enter nothing, if that was not bound to any combination while with the change it enters a capital Z.)