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 `swap_nodes` function was not written to handle nodes from different
desktops. We need to be able to do that in order to move tiled windows
across monitors.
The following 'grab_pointer' arguments are removed: 'move_tiled',
'resize_tiled'. The regular 'move' and 'resize_*' arguments shall be
used instead. The 'fence_grip' parameter is no longer meaningful and
has been removed. Moving and resizing now behaves the same for tiled and
floating windows.
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.
