The front page and docs landing page emphasize documentation, but the user guide looks like it hasn't been updated since 2013. It seems from the history of the file that this number is misleading. Let me know if I'm missing anything.
The old comments gave the impression that you had to define workspace names upfront, which is not true. This also keeps the overall config as brief as possible.
Relabeling the workspaces required the user to update the labels at least in two places of the i3 config file (switch to workspace + move focused container to workspace) to keep a consistent state.
This got even worse when the user started to reference the workspaces elsewhere, e.g. for assigning containers to specific workspaces.
This change supports the DRY principle for users. Relabeling the workspaces is now merely a matter of changing the respective variable ($ws1, $ws2, … $ws10).
Add support for relative coordinates in i3bar click events
Rename {x,y}_rel to relative_{x,y}
Update i3bar-protocol doc to mention the added fields in click events
The problem here is that con_fullscreen_permits_focusing() does not
check if there is a blocking fullscreen container in the workspace that
the container to be focused belongs. This makes it possible to focus a
container behind a fullscreen window if it's in an unfocused workspace.
This commit introduces a change in the 'focus' command behaviour. When
focusing a container blocked by a fullscreen container, either CF_OUTPUT
or CF_GLOBAL, the blocking container loses its fullscreen mode and the
target container is focused like normal.
This should not affect directional focus commands: left, right, up,
down, parent, child.
Fixes issue #1819.
The bug triggers when _workspace_show calls tree_close_internal and
old == old_focus. Ie, when the old workspace was empty and needs to be
closed but then is accessed as output_push_sticky_windows's argument:
Breakpoint 1, output_push_sticky_windows (to_focus=0x55555589c8a0) at ../../i3/src/output.c:102
102 con_move_to_workspace(current, visible_ws, true, false, current != to_focus->parent);
(gdb) print con_exists(to_focus)
$1 = false
The access violation can also be prevented by checking if
con_exists(old_focus) but it shouldn't be necessary: the old_focus
container can only be killed when it is an empty workspace.
With --enable-sanitizers this causes i3 to exit but with
--disable-sanitizers the access violation doesn't reliably cause a crash
and the con_move_to_workspace call continues with:
(gdb) print current != to_focus->parent
$2 = 1
Since current->type is CT_FLOATING_CON and to_focus->type is
CT_WORKSPACE, in this specific case ignore_focus would always be true.
So, in this case, passing NULL instead of old_focus to
output_push_sticky_windows doesn't change the behaviour of i3.
Fixes#3075.
Prevents a false-positive error eg with config file:
set $mod Mod4
bindsym $mod+h split h
bindsym $mod+v split v
ERROR: CONFIG: Expected one of these tokens: <end>, '#', 'set ', ...
ERROR: CONFIG: Line 8: status_command i3status
ERROR: CONFIG: Line 9: }
ERROR: CONFIG: Line 10: <BE><BE><BE><BE><BE><BE>
DebianWall