Example: if one chromium window is opened and a link is opened in
newsbeuter then chromium will steal the input focus (without explicitly
requesting focus via the proper EWMH message).
The new message syntax:
- Provides 10 commands instead of 60.
- Allows multiple actions to be applied in one call.
The client now returns an non zero exit code when a message fails.
The `is_adjacent` function now handles vacant nodes.
When a window is killed, the unmap event is never fired leaving a hole
in the layout. This commit closes that hole by manually calling arrange
after killing.
The fourth argument of `focus_node` was introduced to avoid calling
unneeded functions from `manage_window`: the reason is not good enough
to justify the existence of that extra argument.
The `birth_mode` was not sufficient for properly unrotate the brother of
a removed node. The `birth_rotation` stores the rotation applied to the
brother subtree when the node was inserted.
This should help to enforce that (L + n) - n = L in every possible
cases. Which means that adding a node and removing it should leave the
layout unchanged.
The aforementioned setting, when set, makes the focus movements based on
the distances between the window sides.
The `{prev,next}_leaf` functions were taught not to climb above their
roofs.
This is a fix for the following bug:
https://bbs.archlinux.org/viewtopic.php?pid=1244541#p1244541
I'm not sure why `monsterwm` is immune to this or if there's a better
way to fix it. I've made a test with a simple window listening to
focus{in,out} events and it did receive those events after being
unmapped without needing the fix...
The current implementation of `focus_follows_pointer` requires that the
motion recorder be lowered when `xcb_query_pointer` is called,
otherwise, the response will specify the motion recorder as child
attribute.
The concept of triple border was initially introduced to solve the
visibility problem occurring when the border's environment is similar to
the border itself. In practice however, it doesn't help much and has no
redeeming aesthetic value.
It seems that pointer motion events are not sufficient to enforce
'focus_follows_pointer': some windows grab the pointer and catch those
events (e.g.: *zenity*), preventing *bspwm* from receiving them. So we
need to listen to enter notify events too.
It looks as though commit f37c14902f
introduced a regression in the way urgency borders are rendered. Because
each window is considered across all desktops for monitors, we must now
augment the checking of an urgent client when looking up the border colours
for focused windows also.
Without this, a single window on a desk on an unfocused monitor will be
correctly set as having an urgent hint, but its borders will not pick up on
any urgent border colour settings.
