Re: [hackers] [dwm][patch] Stop input focus on pointers unselected monitor

From: Storkman <storkman_AT_storkman.nl>
Date: Wed, 16 Aug 2023 18:06:40 +0200

On Wed, Aug 16, 2023 at 10:07:16AM +0200, Hiltjo Posthuma wrote:
> On Tue, Aug 15, 2023 at 10:43:32AM +0100, Christopher Lang wrote:
> > When the pointer is on an unselected monitor and is not moving, it
> > should not interfere what window is selected/focused.
> > [...]
> > If focusmon selects a monitor with no clients then XSetInputFocus is
> > called on the root window. Due to the above rules, an FocusIn event is sent
> > to the window under the pointer which may be on another monitor. Now a
> > window on one monitor is getting our keyboard input but another monitor
> > is selected. In this undesirable state, a killclient shortcut (for
> > example) will not destroy the window that is accepting input.

Perhaps more relevantly, if you select an empty monitor and press Mod+P,
dmenu shows up on the monitor the pointer is on, but the program you start
shows up on the selected monitor.
I feel like this has been discussed before on the mailing list...

> >
> > We fix this by focusing on the bar window instead of root when an empty
> > monitor is selected. Windows on other monitors are not a children of the
> > bar window so they will not be focused by a NotifyPointer event.
> > 2:
> >
> > If a window is moved from the selected monitor to the monitor under the
> > pointer and the rearrangement of windows on the second monitor causes a
> > different window to be under the pointer, then an enternotify event is
> > sent for that window. This causes that window to be focused and the
> > second monitor to be selected. If the arrangement on the second monitor
> > did not cause the pointer to be under a different window then the
> > selected monitor would not change (very unpredictable behaviour!).
> > We fix this by suppressing all enternotify events at the end of an
> > arrange(NULL) call.

So currently, if you move a client to another monitor, focus stays on
the same monitor, *unless* your mouse pointer just happens to be in the
master area of the second monitor. I see no reason for this exception,
so in that sense the patch is correct.

> > [...]
>
> Hi,
>
> Thanks for the patch. I'm not yet sure about it.
>
> If there are any other multi-monitor users, please test this and share your
> opinion of if the change makes sense to you.

Seems to work okay so far (applied to master with a bunch of other patches
on top).

>
> --
> Kind regards,
> Hiltjo
>

-- 
Storkman
Received on Wed Aug 16 2023 - 18:06:40 CEST

This archive was generated by hypermail 2.3.0 : Wed Aug 16 2023 - 18:12:48 CEST