On Wed, Aug 16, 2023 at 07:30:05PM +0200, Hiltjo Posthuma wrote:
> 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.
Not just in the master area of the second monitor: after client has been moved
and windows have been arranged. The focus stays on the same monitor unless the
mouse pointer is over a different window than it was before due to the new
arrangement of windows. If there were two windows on the second monitor before
the move, then it is possible the pointer changes from being over one to
another without it being over the master.
>
> 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
>
I will give an example to show just how unpredictable current behaviour
is.
Say you have two tiled monitors: M1 and M2. M1 and M2 each contain a
single client occupying their full area. M1 is selected, the pointer is
in M2. If a keybinding is pressed that moves M1's client to M2, then the
new monitor selected depends on where in M2 the pointer was! (if the
pointer is over the moved window after the move then the selection
changes otherwise selection remains on M1).
I have been using dwm with multiple monitors for about a year now and
have not gotten used to this behaviour.
--
Christopher
Received on Thu Aug 17 2023 - 10:22:16 CEST