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.
An example to set all XTerms floating:
for_window [class="XTerm"] mode floating
To make all urxvts use a 1-pixel border:
for_window [class="urxvt"] border 1pixel
A less useful, but rather funny example:
for_window [title="x200: ~/work"] mode floating
The commands are not completely arbitrary. The commands above were tested,
others may need some fixing. Internally, windows are compared against your
criteria (class, title, …) when they are initially managed and whenever one of
the relevant values change. Then, the specified command is run *once* (per
window). It gets prefixed with a criteria to make it match only the specific
window that triggered it. So, if you configure "mode floating", i3 runs
something like '[id="8393923"] mode floating'.
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).
Actually, commit 1c5adc6c35 commented out code
without ever fixing it. I think this was responsible for the 'workspace
switching sometimes does not work' bug. My observations:
Had it again today and analyzed a log of it. Looks like after unmapping the
windows on one workspace (in my case: chromium, eclipse, urxvt, focus on
eclipse) we get UnmapNotify events for chromium and eclipse, but then we get an
EnterNotify for the terminal (due to unmapping the other windows and therefore
mapping the terminal under the cursor), only afterwards the UnmapNotify
follows.
So, there are two things wrong with that:
• We handle EnterNotifys for unmapped windows
• Unmapping windows sometimes works in a sequence, sometimes the sequence gets
split. Not sure why (if unmapping can take longer for some windows or if our
syncing is wrong -- but i checked the latter briefly and it looks correct).
Maybe GrabServer helps?
• We don’t ignore EnterNotify events caused by UnmapNotifies. We used to, but
then there was a different problem and we decided to solve the EnterNotify
problem in another way, which actually never happened (commit
1c5adc6c35).
According to the Xlib Programming Manual section 10.7.2 [1], these events are
generated when keyboard grabs activate/deactivate, while we are only interested
in focus changes which are done by other programs independend from the
keyboard.
[1] http://tronche.com/gui/x/xlib/events/input-focus/grab.html
This involves:
• Compiling with xcb-util instead of xcb-{atom,aux} (they merged the libraries)
• Not using xcb-{event,property} anymore (code removed upstream)
• Not using the predefined WINDOW, CARDINEL, … atoms (removed upstream)
• Using the new xcb_icccm_* data types/functions instead of just xcb_*
(for example xcb_icccm_get_wm_hints instead of xcb_get_wm_hints)
Also I refactored the atoms to use x-macros.
The Clang Static Analyzer uncovered those issues:
- The variable "changed" in handlers.c is written to, but it's
never read since that specific write, so the write is not
necessary.
- In util.c, "tail" may be NULL. In that case, we shouldn't pass
it to strlen because strlen's behavior is not defined when s is
NULL.
- In util.c, "write_index" is incremented twice. It's never used
anymore after being incremented once, so the second increment is
not necessary.
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.
