Change logics to fix existing issues

[ghost]

Major logic changes, fixes https://github.com/LeonMatthes/mousefollowsfocus/issues/4, fixes https://github.com/LeonMatthes/mousefollowsfocus/issues/5

Note this doesn't use the "temporary deactivation during mouse movement" approach as portrayed here: https://github.com/LeonMatthes/mousefollowsfocus/issues/4#issuecomment-1265908575

[ghost]

@LeonMatthes

[ghost]

Another thing I want to do is to trigger mouse movement when window is resized / moved by keyboard shortcut.

For example:

1. open two windows
2. maximize both
3. you want to work on window A. window B is in background
4. move your mouse to the right side of the screen
5. press Meta + ← to move window A to the left side of the screen

if you have "focus on hover" enabled then window B will be activated, stealing user's focus. this is very annoying if you mainly use keyboard to resize windows.

however i have not come up with a proper idea yet.

[ghost]

I've added mouse movement when currently focused window has size change. position change is included but commented out.

I need a way to suppress/discard event when mouse is pressing/holding, to avoid repeatedly triggering mouse movement and spamming logs.

not having position change detection causes the follwing issue:

• if your window is moved with keyboard shortcut and the size is not changed, your mouse will not follow it
• this seems obvious, but notice Super + Arrow shortcut isn't affected most of time, except when your window is already docked to left of right, then you use Super + ←/→ to move the window, your mouse won't follow it

[ghost]

And yeah, resizing using mouse is completely broken

[LeonMatthes]

Hi @thjderjktyrjkt ,

if I understand your code changes correctly by this comment:

        // ↓ These shouldn't be necessary anymore as it tries to attach to all
        // existing windows but now we don't do that anymore because handling
        // focus change is now done by three separate things:
        // 1. Attaching to `Main.activateWindow` (used by Alt + Tab switcher and
        //    many extensions, e.g. Dash to Dock, Dash to Panel)
        // 2. Attaching to 'window-created' and only start acting when window is
        //    opened in foreground
        // 3. Attaching to overview's `hidden` signal, so that exiting Overviw
        //    also triggers mouse movement

The essence is that you're proposing to switch from using the "focus" event to overwriting Main.activateWindow instead.

I'm honestly unsure what to make of this approach. It captures most actions when extensions (or built-in stuff like alt-tab) actively change focus to a window. However, it's not the "catch all" that we get by actually following the focus.

Therefore it seems almost by accident that those focus change events that are currently "annoying" (i.e. when switching workspaces by mouse scroll) are being ignored by this approach.

Does Main.activateWindow also get called when e.g. using Super+PgUp/PgDown to switch Workspaces? Because in that case, I'd definitely want the cursor to jump to the newly activated window on the new workspace.

I feel like if we rely on Main.activateWindow, we'll end up needing to treat all those special cases, like creating a new window, switching Workspaces by keyboard shortcut, etc.

Overall I think I'd still prefer the approach of disabling the extension for a short time when mouse input is detected. As that should more clearly capture the intent of the user:

If I'm using the mouse, I want to be in control of the cursor. If I'm using the keyboard, I want the extension to take care of moving the cursor for me.

[ghost]

Yes. This is why it's marked as draft rather than ready for merge, it's the case-by-case whitelist-based approach than the once-for-all blacklist-based approach. you should decide if this is the approach you want to have. personally i feel like this is safer, as i know that every mouse movement is triggered by something i know about.

As of switching workspaces with keyboard shortcuts, it could be tough, it's not handled by this PR (yet). i'm not aware of any way to filter out workspace changes that are triggered by keyboard, apart from registering the keyboard shortcuts with this extension directly.

[ghost]

There's a way to move mouse with keyboard workspace change I came up in mind:

Also hook into windowManager.actionMoveWorkspace with an async timer. If another workspace change is detected during this time period, the pending mouse movement is discarded and the new timer is started. this would closely follow my original issue's thought. The time length would be the same of longer than workspace switching animation.

The better way should be hooking into this:

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/gnome-43/js/ui/workspacesView.js#L1094

This is clearly the one used by keyboard shortcuts to trigger workspace change.

Or, not better. Notice the _ in front of function name, it's potentially subject to changes.

It doesn't work.

Also, not that I don't want to implement mouse input detection, it's just that I don't know how to properly implement it.

[LeonMatthes]

Yes. This is why it's marked as draft rather than ready for merge, it's the case-by-case whitelist-based approach than the once-for-all blacklist-based approach. you should decide if this is the approach you want to have. personally i feel like this is safer, as i know that every mouse movement is triggered by something i know about.

As of switching workspaces with keyboard shortcuts, it could be tough, it's not handled by this PR (yet). i'm not aware of any way to filter out workspace changes that are triggered by keyboard, apart from registering the keyboard shortcuts with this extension directly.

Also, not that I don't want to implement mouse input detection, it's just that I don't know how to properly implement it.

I think I'll stick with the blacklist-based approach for now, I really don't want to figure out all the different ways to capture window focus change by keyboard :thinking: As you already explored it's hard to do for some cases and I don't really have much spare time to maintain this extension. Ideally we could find someone more knowledgeable about the mouse input system in Gnome who could help realize the mouse-input event detection. I've already tried using Clutters event filter, but that didn't seem to capture all events for some reason :/

If there's no way to make that work, I'll reconsider this PR again.

Thank you for contributing and moving the discussion forward! I'll close this PR for now. Feel free to use your own fork and give feedback on how it went longer-term.