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.
If the window doesn't respond to the WM_DELETE_WINDOW message, we'll end
up with an unmanaged window. Besides, nodes are already removed after
receiving the corresponding destroy notifications.
