No, I don't think we support that atm. (ie.: the focus follow the mosepointer when it change monitor - focusing the selected window on that monitor) (correct me if I'm wrong hedin)

I'm not sure I'm understanding this one right - you want to have two windows focused (selected?) at the same time?

Need some more information here.

Planning on closing this in a month or so unless it's still an issue or you can provide more information.

No I think the OP just want to turn off the "auto follow focus" (i.e. when you move the mouse to the other monitor, the focus changes to the last active window on that monitor).

I think it is feasible to add a setting for that.

No I think the OP just want to turn off the "auto follow focus" (i.e. when you move the mouse to the other monitor, the focus changes to the last active window on that monitor).

ah, that makes sense. Yes, probably should have a setting for this.

I also would like to disable that. The reason are dialogs that you move to another monitor are pushed in the background what makes it complicated to go back to them:

1. open a window on your second monitor
2. open a dialog from an app on your first screen (for example settings of inkscape)
3. move the dialog on your second screen

Immediately the window loses its focus and the dialog is pushed in the behind the active window on your second screen.

I think adding an option to not have "focus follow mouse" would be fine.

But I also noticed this behavior. Unfortunately in Gnome dialogs are tied to the "parent" window. So if you move a dialog to another monitor than its parent, it gets very hard to control it. Normally in Gnome you can't even interact with the parent window and the dialog is fixed to the center of the parent. But we turn off that behavior because I think it causes some problems for PaperWM.

I don't know if or how we can fix that. It might get pretty complicated because we have to work against some Gnome behavior.

Just wanted to chip in with saying that as a user who primarily navigates between windows and workspaces with the keyboard, adding this option would be extremely valuable to me, regardless of the dialogs issue.

new user here, with 2 monitors (with different sizes, if that matters somehow): I think I also see this issue on my system.
I still try to figure out the whole behavior so I am unsure what is a feature and what is a bug (maybe) ;-)

Hello,

I'm a huge fan of sloppy focus, I was even using sloppy focus with PaperWM (sometimes with the help of other extensions). At some point, the behavior of PaperWM changed a bit and some helper extensions I was using were abandoned, so I turned off sloppy focus.

So the "focus follow the mouse pointer when it changes monitor" behavior is not a big deal to me. In fact, what I look strange and see as a bit of inconsistency is that the "focus follow the mouse pointer" only "when it changes monitor".
I'd even say that in the current case it's not that the focus follow the mouse: I can move the mouse pointer to my second screen, the focus will change from screen but the windows receiving the mouse pointer will be the one focused only if it was "the last focused window on this screen".
In our case, it's more : the mouse pointer follows the focus only when the focus changes from one screen to another.

I understand people that don't like this behavior and would like it to be disabled but in some cases it makes perfect sense: often, if I change the focused screen, chances are high that I'll need the mouse cursor to be around.

So please, don't purely disable this behavior and please and a parameter for that, something like:

• Disabled: changing screen with keyboard won't touch the mouse pointer
• Screen: keep the current behavior
• Window: the mouse pointer follows the focus changes from the keyboard, putting the mouse pointer in the center of the focused window (I would love it, there was an extension for that but it used to not work well with PaperWM)

Thanks for reading

Hello,

I'm a huge fan of sloppy focus, I was even using sloppy focus with PaperWM (sometimes with the help of other extensions). At some point, the behavior of PaperWM changed a bit and some helper extensions I was using were abandoned, so I turned off sloppy focus.

So the "focus follow the mouse pointer when it changes monitor" behavior is not a big deal to me. In fact, what I look strange and see as a bit of inconsistency is that the "focus follow the mouse pointer" only "when it changes monitor". I'd even say that in the current case it's not that the focus follow the mouse: I can move the mouse pointer to my second screen, the focus will change from screen but the windows receiving the mouse pointer will be the one focused only if it was "the last focused window on this screen". In our case, it's more : the mouse pointer follows the focus only when the focus changes from one screen to another.

I understand people that don't like this behavior and would like it to be disabled but in some cases it makes perfect sense: often, if I change the focused screen, chances are high that I'll need the mouse cursor to be around.

So please, don't purely disable this behavior and please and a parameter for that, something like:

• Disabled: changing screen with keyboard won't touch the mouse pointer
• Screen: keep the current behavior
• Window: the mouse pointer follows the focus changes from the keyboard, putting the mouse pointer in the center of the focused window (I would love it, there was an extension for that but it used to not work well with PaperWM)

Thanks for reading

Hey @bilboquet, as you mentioned this issue is a little different - I've created a ticket for the "mouse follows focus" approaches you're referring to #756.

Hey @bilboquet, as you mentioned this issue is a little different - I've created a ticket for the "mouse follows focus" approaches you're referring to #756.

Many thanks, at first that was just a comment, I'm glad you're considering it.

I think adding an option to not have "focus follow mouse" would be fine.

So, after attempts at implementing an option for this (see PR #755) , we now understand why this isn't currently feasible with the way PaperWM manages multiple monitors (i.e. one workspace per monitor).

Note that "one workspace per monitor" is a PaperWM implementation - Gnome does not natively have this (although it's been requested multiple times: https://gitlab.gnome.org/GNOME/mutter/-/issues/37). Gnome has a "one workspace across all monitors" paradigm.

The reason why we can't implement this nicely, is that only one meta.workspace can be activated at a time (see https://gjs-docs.gnome.org/meta13~13/meta.workspace) and for unactivated workspaces:

Only one workspace of a screen may be active at once; all windows on all other workspaces are unmapped.

Being unmapped impacts how windows respond (or don't respond) to various signals and events (which are needed for normal window operations). Now, this isn't a problem in vanilla Gnome since it uses one workspace across all monitors - meaning that if you've got multiple monitors, you're actually using a single workspace (i.e. all windows across monitors are mapped).

PaperWM on the other hand, actually has a different workspace on each monitor. Which is why, it's always needed to activate the workspace (which focuses window on that workspace) when moving mouse to another monitor.

To be able to implement this (not focusing windows when moving mouse to another monitor), we'd have to:

• remove PaperWM's implementation of one workspace for monitor, basically using Gnome's paradigm for multimonitors;
• or accept the above and need to manually activate the workspace by clicking it on another monitor, which is what Feature: add option to enable/disable "multimonitor focus follows mouse" #755 does, but there are issues, inconveniences involved:
  • Feature: add option to enable/disable "multimonitor focus follows mouse" #755 (comment)
  • Feature: add option to enable/disable "multimonitor focus follows mouse" #755 (comment)

Note, from a code/development pov, one workspace per monitor (note: I don't use multiple monitors that often!) is a complex beast, and it's the cause of most of PaperWM's multi monitor issues, i.e. we have to fight against Gnome default behaviours (it would be nice for it to be natively supported in Gnome - but they have their own priorities etc). That said, it is a big part of PaperWM's codebase and a selling point(?). It would also be a very large refactor/change.

Thoughts?

Hello,
@jtaala, you've asked for feedback so, even if I'm not the OP, as I'm really grateful for what you're contributing, I'm coming with my 2cents.

First, as a disclaimer, I'm a sloppy focus lover (I had to turn it off, but anyway) so the behavior described in this issue is not a problem for me, I like it ^^.

Next, I don't understand what would be the consequences (from a user point of view) of

removing PaperWM's implementation of one workspace for monitor, basically using Gnome's paradigm for multimonitors;

If that does not introduce some kind of synchronization between the screens (ex: I would not like that 3 fingers swiping moves the windows on all screens) I'd say: let's go, make your dev life easier.

Regardless of the solution, I think it is important to make your life as a developer easier.

@jtaala at least I understand now why it is not possible to change that without gnome changing something. and that means, that the main concept of paperwm is not supported by gnome and the whole multi monitor thing is just a workaround.

If I'm not mistaken the inactive monitors show a screen capture of the state when the mouse left the screen, right? And it has to be above all other windows. While I'm dragging a dialog to another monitor this screen capture stays below the dragged dialog. As soon as I lift the mouse button we capture a screen of the other monitor and switch the desktop. As the dialog is always on the same desktop as the main window it can not be shown anymore.

I first thought it is because of the focus of the window and is just behind the other window.

Another thought: when we put all dialogs on the scratch layer - would that help? but that is also weird: the dialog gets moved to another desktop when you drag it and the main window follows. that means the main window is not there when the screen is captured and it gets hidden.

If I'm not mistaken the inactive monitors show a screen capture of the state when the mouse left the screen, right?

Hey @tflori - no this is not correct. They're actually windows (no screenshots are involved) - however, we're simulating an actual gnome workspace on the other monitor (which isn't possible on normal gnome as a single workspace is used across all monitors.

So, basically, given we're actually linking a workspace to another monitor (again, not normal Gnome behaviour)- we need to activate the workspace as we map each of the windows to said workspace. In Gnome, since you can only have one workspace active at a time, we need to be able detect when the mouse moves to another monitor (to activate the workspace and enable windows to receive signals and work as normal.

Hence, that's what happens when we move the mouse, we track mouse movements and when it move to another monitor, we activate the workspace on that monitor, which enables the windows to accept events/signals etc.

If that does not introduce some kind of synchronization between the screens (ex: I would not like that 3 fingers swiping moves the windows on all screens) I'd say: let's go, make your dev life easier.

Unfortunately, that's exactly what it would do - like normal Gnome, e.g. in normal Gnome if you drag a window from one monitor to another - it's as if it's just one large workspace (whereas in PaperWM you have a boundary and the window "moves" from one workspace to another).

You can see how neat that is - PaperWM actually implements "separate workspaces on monitors". Although it's not without it's issues, mainly because it's not currently possible on normal Gnome and hence we're fighting against Gnome's current design.

Now, we wouldn't likely change this behaviour - and just accept that we're definitely not following Gnome's design re multimonitors... and hence there's going to be some rough parts, bugs, and limits to what we can currently do when it comes to PaperWM multimonitor.