9.3 Border Crossing and Keyboard Focus Change Events
events are generated when the pointer crosses a window border. If the
window manager is of the real-estate-driven variety (as is
uwm), you might be tempted to assume that a
LeaveNotify event indicates that the window will not
receive keyboard input until it receives a matching
EnterNotify. However, this assumption is not true if
the user has been allowed to set a keyboard focus window. It is also not
true if the window manager is of the listener variety (see Chapter 1, Chapter 12,
and Chapter 16). Ideally, you should be
prepared to deal with either type of window manager.
Pointer input can only be delivered to a window when the pointer is inside the window (unless the window grabs the pointer). Therefore, an application that depends on pointer input can expect to be idle when the pointer leaves the window and to be active again when the pointer enters. Notice that keyboard input can be diverted with the keyboard focus or grabs, while pointer input can only be diverted by grabs.
occur when the keyboard focus window changes (when some client calls
XSetInputFocus()). By using focus events together with the border crossing events, an application should be able to determine whether or not it can get keyboard input. If it cannot get keyboard input, it may change its behavior somewhat. If it polls for keyboard input to allow for interrupts, it can stop polling. If it normally highlights ...