`vlog()` can not handle log messages longer than 4096 bytes. However, the
message generated in `store_restart_layout()` is likely to exceed this
as it contains a long JSON string.
This has caused a few SEGFAULTS during restarts for me when running with
`-d all`.
Fix this by truncating the message to 4096 bytes and punching in a newline at
the end.
This fixes a bug I introduced in #1921. When restarting i3 in place a
stray workspace was created on the root_output during restart. On first
start, this workspace would have been moved to the first real and empty
output.
However, this does not produce the desired result during restarts when
workspaces are alread present on all real outputs. The stray workspace would
still be added to the first real output which already contains some
workspaces. Thus, adding a new empty workspace to it.
Fix this by delaying creation of the root output's workspace until it is
known whether the output is active or not.
Fixes#1940
This is necessary during a restart of i3 when restoring floating windows. In this situation, we restore the layout before setting up the RandR outputs which would set the window's size to 0, making it invisible.
Thanks to hwangcc23 and spudowiar for reporting.
fixes#1910fixes#1934
1. Reference: issue #1929
2. When restarting, add the argument "-d all" if debuglog is on.
3. Add add_argument() for adding/replacing the given argument.
This patch introduces a root output covering the root window. It is used
in two cases:
1. RandR is not available. In this case, the previous behaviour of
creating a single output covering the root window is preserved.
2. RandR is available, but there is no active output. In this case,
the root output is enabled and will be the only active output.
If any RandR output becomes available, the root output will be
disabled again. Existing mechanisms for migrating workspaces will
just work without modification.
I've carefully slipped in a global variable `Output root_output` representing
that output.
Fixes#926 and #1489
This commit also reworks the way focusing sticky windows is prevented by not focusing them temporarily at all, but preventing the focus in the first place.
If no other window is available on the active workspace, we now select the EWMH support window (used to indicate that an EWMH-compliant window manager is preent) as the focus window rather than the root window. The NET_WM_ACTIVE window will still be set to XCB_WINDOW_NONE to pretend that no window is actually focused.
This fixes the issue that when using the root window, a fallback mechanism in X11 takes effect which routes keyboard input to the window under the cursor, independent of whether that window has the input focus. Using the EWMH window instead, we can avoid this behavior. We cannot simply set it to XCB_WINDOW_NONE as this would discard all keyboard events, breaking keybindings.
fixes#1378
Reordering once (as we did it before this commit) would only sort the
bindings by the _first_ bit of their event_state_mask, but we need to
sort them by _all_ bits of their event_state_mask.
fixes#1870
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.
This reverts commit e71c304444.
It turns out that several users have workflows in which they turn off
their monitors without using e.g. `xrandr --output DP-1 --off`. The
result is that the monitors are disconnected, but not disabled.
With commit e71c304444, i3 started to see
these two states as one and the same state, but that causes more harm
than it does good. For example, for some users with only one monitor, i3
would just exit when these users turned off their monitor.
related to #1858, #1839fixes#1845
With commit c738b2e454 we changed i3 so
that the default keybindings can be used when ISO_Next_Group is enabled,
but bindings which explicitly use Mode_switch have precedence. This
behavior required the use of bindcode instead of bindsym.
With this commit, when switching from group 1 to group 2 using
ISO_Next_Group, i3 will re-translate all keybindings (looking at column
2/3, regardless of whether the keybinding itself specifies Mode_switch)
and re-grab them.
That way, the keybinding “bindsym $mod+x nop foo” will work when
pressing $mod+x without Mode_switch and when pressing the corresponding
$mod+x (different key) with Mode_switch. A binding such as “bindsym
Mode_switch+$mod+x nop bar” will still have precedence.
The intention here is to make bindsym keybindings work well with dual
keyboard layouts (such as {dvorak, us} or {us, ru}), so that users can
switch between groups and still have their (logical) keybindings behave
the same way.
fixes#1775
hwangcc23