Modify _tree_next() so that when we reach the workspace container:
1. Find the next corresponding output (screen) using the added
get_output_next().
2. If there is another output, find the visible workspace.
3. Call workspace_show on found workspace.
4. Find the appropriate window to focus (leftmost/rightmost, etc.) using
con_descend_direction, and then focus it.
I've only tested on horizontal monitors (left/right).
These errors can happen because a DestroyWindow request by a client will
trigger an UnmapNotify, then a DestroyNotify. We cannot distinguish this
UnmapNotify from an UnmapNotify not followed by a DestroyNotify, so we just try
to send the ReparentWindow / ChangeProperty and ignore the errors, if any.
Think of the following layout:
-------------
| tab | |
| con | win |
| | |
-------------
The tabbed container on the left has two children. Assume you have focused the
second/right child in the tabbed container. i3 used to focus the first/left
container of the tabbed container when using 'focus right' (it wrapped focus).
With this commit, the default behaviour is to instead focus the window on the
right of the screen.
The intention is to make focus switching more intuitive, especially with tabbed
containers supporting 'focus left'/'focus right' in tree. You should end up
using less 'focus parent' :).
You can force the old behaviour with 'force_focus_wrapping true' in your
config.
Code coverage is 62.5% with this commit.
New containers were previously attached directly to the workspace instead of to
the previously focused place in the workspace (for example a stacked con).
Fixes: #376
Use 'kill window' to kill a specific window (for example only one specific
popup), use 'kill client' to kill the whole application (or X11 connection to
be specific).
When a tabbed container had more than one child and at least the first one
supported WM_DELETE, i3 entered an endless loop when killing that tabbed
container. This was due to tree_close only sending WM_DELETE without actually
removing the child, while the loop in tree_close assumed that with every call
of tree_close one child would be removed.
Due to lots of cases which were added and added to tree_move(), the function
was not really easy to understand. For this refactoring, I wrote tree_move()
from scratch, thinking about (hopefully) all cases. The testsuite still passes.
The move command also has different parameters now. Instead of the hard to
understand 'before v' stuff, we use 'move [left|right|up|down]'.
If we're not killing the mapped window and we're not killing the
parent window either in tree_close, then there's no reason to try
to change the focus. This fixes focus issues when moving a
container around another container (move up, left, bottom, right).
Instead, we attach them to their workspace when toggling back to tiling. This
makes more sense; afterall, floating clients are always directly below a
CT_WORKSPACE container.
The problem was i3 leaving an invalid focus pointer valid (after killing the
container) because the container itself is not mapped (if it has no x11 window,
for example split containers).
The file is now created in /tmp using the process PID and the
username of the user running i3. The restart state file is only
loaded when restarting (the --restart option is appended to the
command line prior to the restart). That means that renaming the
old state file with the ".old" extension is no longer needed.
This "--restart" switch is supposed to be only used by i3. The
"-L" switch can be used to load a layout (and not delete it
afterwards). We unlink the state file after we load it so that
we don't keep cruft in /tmp or try to restart from an old config
file if restart_state is set.
When having two v-splits on a horizontal desktop:
----------------
| t1 | t3 |
|-------|------|
| t2 | t4 |
----------------
…focus is on t2, and you move it into the right v-split (move after h), the
focus was not properly updated. That is, inside the right v-split, focus was
correct, but the workspace focus was still pointing to the left v-split.
Numbered workspaces (workspaces with a name containing only digits) will be
inserted in the correct order now. Named workspaces are always sorted after
numbered workspaces and in the order of creation.
This fixes the bug which caused floating windows to be visible even when
switching to a different workspace.
Instead of ignoring a specific sequence, we now set an ignore_unmap counter for
each container. (So, should containers be closed too early or stay open even if
they should be closed, we probably need to have a closer look at the counter.
At the moment, it is increased by one on reparenting and unmapping (for
workspace changes) and decremented by one on each UnmapNotify event).
This system is better because a sequence does not describe a single unmap or
reparent request but a request to X11 on the network layer -- which can contain
multiple requests.
Michael Stapelberg