Oliver Graff [Sat, 31 Mar 2018 19:56:59 +0000 (15:56 -0400)]
Workspace renaming: Interpret outputs as nondirectional
Currently when renaming outputs, an output assignment of "left" will
cause the workspace to move left. Treat this assignment as a proper name
instead (even though it is unlikely an output will be named "left").
Move logic for determining output to move to out of
`workspace_move_to_output`
Add test for ignoring direcionality during rename.
Orestis Floros [Sat, 31 Mar 2018 23:02:50 +0000 (02:02 +0300)]
Window decoration scrolling: don't focus sibling
The current behaviour is buggy in the following layout:
T [ A* V [ B C ] ], where the focus stack in V is B > C.
When the user scrolls down, focus correctly moves to B but if the user
scrolls down again the whole vertical container is focused.
This happens because 'bool scroll_next_possible' is false but
con_activate is called on the tabbed container's sibling - the vertical
container.
i3bar’s X11 output is not what our testcases are testing — the state
manipulations which i3bar triggers via IPC messages to i3 are what we are
interested in.
Sending the sync command via IPC ensures pending IPC messages are handled by i3
before the sync response is read. This is rarely useful for direct IPC
connections to i3, but becomes useful when synchronizing with i3bar, which might
have pending IPC messages in response to button clicks.
Remove special handling of floating containers in con_next_focused
Explanation for the changed test:
After $third is switched to floating, the test moves focus to $second.
So, the parent of $second (the stacked container) is above $third in the
focus stack and it's children ($first, $second) should get focused
before $second. When $second is switched to floating the correct focus
order for the workspace should be $second->parent (floating con is the
parent) > $first->parent (stacked con) > $third.
2. Run `python2 ./xproperty.py _XKB_RULES_NAMES ''` (from
https://github.com/siemer/xproperty) in the xinitrc
3. Memory sanitizers detect memory leaks.
Note: We don't (and didn't) pass NULL in xkb_keymap_new_from_names() but
an xkb_rule_names structures with NULL fields (fill_rmlvo_from_root only
fills its argument when there are no errors) should be equivalent:
https://github.com/xkbcommon/libxkbcommon/blob/767fa86d42a5e25e7043622d189247e02a5ca379/NEWS#L349-L351
> The function xkb_keymap_new_from_names() now accepts a NULL value for
the 'names' parameter, instead of failing. This is equivalent to passing
a 'struct xkb_rule_names' with all fields set to NULL.
Orestis Floros [Sun, 25 Mar 2018 01:45:19 +0000 (04:45 +0300)]
_con_move_to_con: don't change focus when moving to active workspace
Seems to be the intention, indicated by this comment (con.c:1307-1309):
/* For split containers, we use the currently focused container within it.
* This allows setting marks on, e.g., tabbed containers which will move
* con to a new tab behind the focused tab. */
Elouan Martinet [Tue, 20 Mar 2018 13:06:17 +0000 (13:06 +0000)]
Fix potential memory leak
xkb_state_new uses calloc and may fail in a rare case, which would cause a memory leak.
Note that xkb_state_unref checks if the parameter given is not null (!state) before freeing.
Calls to xkb_state_new have been grouped to remove code duplication.
con_next_focused uses con's parent. But since con can be inside an
unfocused container this means that one of it's siblings could become
focused in the current workspace.
Orestis Floros [Fri, 23 Mar 2018 10:56:30 +0000 (12:56 +0200)]
_con_move_to_con: showing target_ws is useless
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
Orestis Floros [Sat, 17 Mar 2018 18:43:11 +0000 (20:43 +0200)]
floating_maybe_reassign_ws: use get_output_from_rect
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.
Orestis Floros [Sat, 17 Mar 2018 15:47:16 +0000 (17:47 +0200)]
floating_enable: change reassign logic
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 */
Tony Crisci [Mon, 25 Jul 2016 00:43:56 +0000 (20:43 -0400)]
Support _NET_WM_STATE_FOCUSED
_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.
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.
Orestis Floros [Mon, 19 Mar 2018 16:30:22 +0000 (18:30 +0200)]
Fix userguide link
[[move_to_outputs]] doesn't work currently:
https://i3wm.org/docs/userguide.html#move_to_outputs
This does:
https://i3wm.org/docs/userguide.html#_moving_containers_workspaces_to_randr_outputs
This combines a 'BlockId Element' with an 'anchor'. Both should work
now.
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."}]
Tony Crisci [Mon, 25 Jul 2016 00:43:09 +0000 (20:43 -0400)]
testcases: remove assumption from state atoms test
Remove the assumption that only two atoms can possibly be set in
t/253-multiple-net-wm-state-atoms.t so that the tests will pass when
more atoms are supported that may be set during this test.
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.
projects / i3 / i3 / log