Orestis Floros [Sun, 18 Mar 2018 00:08:16 +0000 (02:08 +0200)]
Remove 'method' from cmd_move_window_to_position
For command:
move window to [absolute] position X px Y px
if the optional keyword 'absolute' is provided the end result is the
same even though it is implemented differently. Only difference is that
with absolute the floating window can move completely outside of any
output.
This commit removes the 'method' argument and only keeps the sane
implementation.
This means that the pointers stored in window->ran_assignments are
invalid (shouldn't be dangerous currently but could lead to a segfault
if the code is modified) after a 'reload'.
Orestis Floros [Sun, 18 Mar 2018 01:38:06 +0000 (03:38 +0200)]
i3-msg: only print input + errorposition if they exist
Before:
$ i3-msg floating disable, move window to position 100 px 100 px
ERROR: Your command: (null)
ERROR: (null)
ERROR: Cannot change position of a window/container because it is not floating.
[{"success":true},{"success":false,"error":"Cannot change position of a window/container because it is not floating."}]
After:
$ i3-msg floating disable, move window to position 100 px 100 px
ERROR: Cannot change position of a window/container because it is not floating.
[{"success":true},{"success":false,"error":"Cannot change position of a window/container because it is not floating."}]
Fixes:
- Issue where moving an urgent (unfocused) window resets it's urgency
hint.
- Moving an unfocused container to a new parent should not move it to
the top of the focus stack.
Ingo Bürk [Sat, 10 Mar 2018 18:18:44 +0000 (19:18 +0100)]
Refocus focused window for FOCUS_IN events on the root window. (#3097)
This deals with (admittedly somewhat misbehaving) clients which
use XSetInputFocus to take focus, but then don't properly restore
focus. This has been observed with TK apps, but also, e.g., Steam.
Orestis Floros [Mon, 26 Feb 2018 01:26:05 +0000 (03:26 +0200)]
Don't raise floating windows when workspace is shown
From comment:
https://github.com/i3/i3/issues/2990#issuecomment-368345169
To easily reproduce:
1. Open 2 floating windows
2. Focus (with `focus_follows_mouse`) the one behind
3. Move the mouse to the other workspace
4. Move the mouse inside the previous workspace (without it even
touching a window)
Ben Creasy [Mon, 19 Feb 2018 02:44:40 +0000 (18:44 -0800)]
Remove hardcoded 2013 date
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.
Thomas Praxl [Tue, 26 Dec 2017 10:29:42 +0000 (11:29 +0100)]
Shorten comment for workspace variables
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.
Thomas Praxl [Sat, 23 Dec 2017 11:28:03 +0000 (12:28 +0100)]
Add workspace vars to support DRY when customizing
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).
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.
Orestis Floros [Sat, 9 Dec 2017 20:17:48 +0000 (22:17 +0200)]
Prevent access of freed workspace in _workspace_show
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.
projects / i3 / i3 / log