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.
