On Wed, Aug 16, 2023 at 06:06:40PM +0200, Storkman wrote:
> 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...
>
Probably................
> > >
> > > 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.
Thanks for sharing, it sounds good.
It's not always very clear what the correct or expected behaviour should be or
what all people prefer. Even though it may sound obvious to one person. I want
to be careful about changing such things, considering this behaviour has been
in dwm for many years.
For example a while ago there was a patch for fullscreen behaviour:
https://git.suckless.org/dwm/commit/67d76bdc68102df976177de351f65329d8683064.html
https://git.suckless.org/dwm/commit/138b405f0c8aa24d8a040cc1a1cf6e3eb5a0ebc7.html
Currently I'm not a heavy multi-monitor user either.
But I'm still curious about this change of course.
>
> > > [...]
> >
> > 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
>
--
Kind regards,
Hiltjo
Received on Wed Aug 16 2023 - 19:30:05 CEST