nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
gri3-wm/src/key_press.c

36 lines
981 B
C
Raw Normal View History

use I3__FILE__ for DLOG, leave __FILE__ as is See also commit 0e752070ac2bed02d0858bbc450ddcee36e3b9b5, which broke source code listings in gdb unless you cd into i3/src. This should give us best of both :-).
2012-08-12 12:18:43 +02:00
#undef I3__FILE__
#define I3__FILE__ "key_press.c"
Display i3-nagbar when commands lead to an error 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).
2012-08-02 17:43:00 +02:00
/*
* vim:ts=4:sw=4:expandtab
*
* i3 - an improved dynamic tiling window manager
Update copyright notices and get rid of ranges The script used to make these changes can be found at: https://gist.github.com/Deiz/32322020f76d23e2bf8f
2015-04-04 02:17:56 +02:00
* © 2009 Michael Stapelberg and contributors (see also: LICENSE)
Display i3-nagbar when commands lead to an error 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).
2012-08-02 17:43:00 +02:00
*
* key_press.c: key press handler
*
*/
#include "all.h"
/*
naive implementation of 'bindsym --release' (and bindcode) 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.
2012-09-06 17:04:31 +02:00
* There was a KeyPress or KeyRelease (both events have the same fields). We
* compare this key code with our bindings table and pass the bound action to
* parse_command().
Display i3-nagbar when commands lead to an error 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).
2012-08-02 17:43:00 +02:00
*
*/
void handle_key_press(xcb_key_press_event_t *event) {
Use libxkbcommon for translating keysyms, support all XKB groups. 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.
2015-08-23 22:49:32 +02:00
const bool key_release = (event->response_type == XCB_KEY_RELEASE);
Display i3-nagbar when commands lead to an error 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).
2012-08-02 17:43:00 +02:00
last_timestamp = event->time;
Use libxkbcommon for translating keysyms, support all XKB groups. 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.
2015-08-23 22:49:32 +02:00
DLOG("%s %d, state raw = 0x%x\n", (key_release ? "KeyRelease" : "KeyPress"), event->detail, event->state);
Display i3-nagbar when commands lead to an error 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).
2012-08-02 17:43:00 +02:00
Refactor binding accessor 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
2014-05-02 16:22:40 +02:00
Binding *bind = get_binding_from_xcb_event((xcb_generic_event_t *)event);
/* if we couldn't find a binding, we are done */
if (bind == NULL)
return;
Display i3-nagbar when commands lead to an error 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).
2012-08-02 17:43:00 +02:00
Feature: implement mouse bindings 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
2014-06-17 15:34:13 +02:00
CommandResult *result = run_binding(bind, NULL);
Refactor parse_command 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.
2014-05-28 08:01:50 +02:00
command_result_free(result);
Display i3-nagbar when commands lead to an error 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).
2012-08-02 17:43:00 +02:00
}