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.
It will facilitate debugging and also provide an exhaustive
representation of the current state that might be used to reconstruct
the layout of each desktops. While doing so, it occurred to me that the
*born_as* attribute of the *node_t* structure was only used for leaves,
so I changed it into a *client_t* attribute.
Ensure the explicitly non-focused monitor with a focused window has its
borders down correctly when 'active_border_color' is used.
Previously, the checks handling this did not set the correct monitor to use.
