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.
Quote from the source:
When the container type is CT_WORKSPACE, the user wants to change the
whole workspace into stacked/tabbed mode. To do this and still allow
intuitive operations (like level-up and then opening a new window), we
need to create a new split container. */
As initial may be set to true again after initializing the window, we need to
ensure that it is properly cleared. Otherwise, this leads to ghost windows when
unmapping (such as the Xpdf about dialog) due to i3 issuing MapWindow after an
Unmap happened but before i3 actually received/handled the UnmapNotify.
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.
