The current_ws is shown latter anyway:
if (!ignore_focus) {
workspace_show(current_ws);
...
This also causes the following bug:
- Open a window in an empty workspace
- Switch to another workspace
- seturgent to the first window
- Move another window to the first workspace
- Urgent flag is now reset
This significantly reduces the number of ELOGs while dragging floating
containers. The behaviour is improved since floating containers in the
edge of the screen will still get reassigned to their closest workspace.
For example, consider this setup:
fake-outputs 500x500+0+0,500x500+500+0
Now, open a window in the right output and run:
i3-msg floating enable, move position 0 px 450 px
The window is on the bottom edge of the left workspace but if you run:
i3-msg focus mode_toggle
focus will go to the right workspace since floating_maybe_reassign_ws
didn't change the assigned workspace of the floating container.
This allows the floating container's top left corner to be mapped
outside any output as long as they are contained partially by one. This,
for example, will allow:
mpv --geometry +1+1 video.mp4
For windows mapped to (0, 0) see comment in floating.c:270-273:
/* Some clients (like GIMP’s color picker window) get mapped
* to (0, 0), so we push them to a reasonable position
* (centered over their leader) */
The floating_reassign_ws call is removed since we try to place the new
floating container in the current output:
/* Sanity check: Are the coordinates on the appropriate output? If not, we
* need to change them */
Fixes#1341
_NET_WM_STATE_FOCUSED is set on _NET_WM_STATE to indicate that the
window is focused. It must be set when the window is newly focused and
removed once the window no longer has focus.
> _NET_WM_STATE_FOCUSED indicates whether the window's decorations are
> drawn in an active state. Clients MUST regard it as a read-only hint.
> It cannot be set at map time or changed via a _NET_WM_STATE client
> message.
For example, this is used by GTK applications to show the decoration in
an active or inactive state. This change can be tested by opening a GTK
application (like evince), focusing the window and unfocusing the
window, and observing a change in the window decorations.
Fixes#2273
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.
When we run 'reload' all the assignments are freed:
e3e09119bf/src/config.c (L99-L109)
Assignments are saved to each window after they are executed:
e3e09119bf/src/assignments.c (L41-L46)
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'.
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.
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.
fixes#2722fixes#3096
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)
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.
Orestis Floros