fixes#1835
This commit improves the translation of keysyms to keycodes by loading
keymaps using libxkbcommon-x11 and using libxkbcommon for figuring out
the keymap, depending on each keybinding’s modifiers. This way, the
upper layers of complex layouts are now usable with i3’s bindsym
directive, such as de_neo’s layer 3 and higher.
Furthermore, the commit generalizes the handling of different XKB
groups. We formerly had support only for two separate groups, the
default group 1, and group 2. While Mode_switch is only one way to
switch to group 2, we called the binding option Mode_switch. With this
commit, the new names Group1, Group2 (an alias for Mode_switch), Group3
and Group4 are introduced for configuring bindings. This is only useful
for advanced keyboard layouts, such as people loading two keyboard
layouts and switching between them (us, ru seems to be a popular
combination).
When grabbing keys, one can only specify the modifier mask, but not an
XKB state mask (or value), so we still dynamically unbind and re-bind
keys whenever the XKB group changes.
The commit was manually tested using the following i3 config:
bindsym Group4+n nop heya from group 4
bindsym Group3+n nop heya from group 3
bindsym Group2+n nop heya from group 2
bindsym n nop heya
bindsym shift+N nop explicit shift binding
bindsym shift+r nop implicit shift binding
bindcode Group2+38 nop fallback overwritten in group 2 only
bindcode 38 nop fallback
…with the following layout:
setxkbmap -layout "us,ua,ru,de" -variant ",winkeys,,neo" \
-option "grp:shift_caps_toggle,grp_led:scroll" \
-model pc104 -rules evdev
By default (xkb group 1, us layout), pressing “n” will result in the
“heya” message appearing. Pressing “a” will result in the “fallback”
message appearing. “j” is not triggered.
By pressing Shift+CapsLock you switch to the next group (xkb group 2, ua
layout). Pressing “a” will result in the “fallback overwritten in group
2 only” message, pressing “n” will still result in “heya”. “j” is not
triggered.
In the next group (xkb group 3, ru layout), pressing “a” will result in
the “fallback” message again, pressing “n” will result in “heya”,
“j” is not triggered.
In the last group (xkb group 4, de_neo layout), pressing “a” will still
result in “fallback”, pressing “n” will result in “heya”, pressing “j”
will result in “heya from group 4”.
Pressing shift+n results in “explicit shift binding”, pressing shift+r
results in “implicit shift binding”. This ensures that keysym
translation falls back to looking at non-shift keys (“r” can be used
instead of ”R”) and that the order of keybindings doesn’t play a role
(“bindsym n” does not override “bindsym shift+n”, even though it’s
specified earlier in the config).
The fallback behavior ensures use-cases such as ticket #1775 are still
covered.
Only binding keys when the X server is in the corresponding XKB group
ensures use-cases such as ticket #585 are still covered.
A configured mouse binding (for example `bindsym button3 kill`) runs
its command when the mouse button is pressed over parts of a container.
If the binding has no modifer, it will only run when the button is
clicked on the window titlebar.
Otherwise if the binding has a modifier, it will run over the titlebar
or any part of the contained window.
fixes#558
Add run_binding function to bindings.h.
> Runs the given binding and handles parse errors. Returns a
> CommandResult for running the binding's command. Caller should render
> tree if needs_tree_render is true. Free with command_result_free().
parse_command returns a struct that contains useful information about
the result of a command as a whole (instead of the intermediate
representation used during parsing).
parse_command now requires the caller to allocate the yajl_gen used for
generating a json reply. This is passed as the second parameter to
parse_command. If NULL is passed, no json reply will be generated.
Change the name of structs CommandResult and ConfigResult to
CommandResultIR and ConfigResultIR to show they are an intermediate
representation used during parsing.
Change the primary binding accessor to `get_binding_from_xcb_event`.
This function gets a binding from a generic xcb event of type KeyPress,
KeyRelease, ButtonPress, or ButtonRelease by determining the input type
(keyboard or mouse), the modifiers pressed from the filtered event
`state`, managing the proper fall back in case mode switch is enabled,
and finally querying the bindings for a binding that matches the event.
The logic of querying keyboard bindings is not intended to be altered by
this change.
The general accessor has been slightly modified to work with mouse
bindings and made private because it is only used in bindings.c
Rename `get_binding` to `get_keyboard_binding` and ensure that this
function only accesses bindings of type B_KEYBOARD. Other types of
bindings (e.g. mouse bindings) will be accessed by a different function.
The implementation is naive because the user has to generate exactly the
event he specified. That is, if you use this binding:
bindsym --release $mod+x exec import /tmp/latest-screenshot.png
Then it will only be triggered if you hit $mod, hit x, release x,
release $mod. It will not be triggered if you hit $mod, hit x, release
$mod, release x. The reason is that the KeyRelease event in the latter
case will not have the modifier in its flags, so it doesn’t match the
configured binding.
e.g. pressing Mod1+x when having the following in your configfile:
bindsym Mod1+x some invalid command
will lead to an i3-nagbar instance popping up, offering you to view the
error log (which will contain parser errors from this commit on).
Ingo Bürk