feat: add options to skip cursor warps

[memchr]

Abstruct

Adds a config general:no_cursor_warps_if_focused which, if true,
allows the cursor to the cursor to stay in place if it is already in the
focused window. This can help reduce unnecessary cursor movement.

Affects all cursor warps.

doc: hyprwm/hyprland-wiki#340

[thejch]

imo a better way to deal with #3266 would be to have a config option to not force focus on the "last active window" or warp the cursor at all, and just focus on the window under the cursor (which is just the previous behavior, and honestly nobody was having an issue with it at all)
a lot of people dont like their cursor being warped around when switching workspaces at all, especially when there's also a popular keybind of mod+scroll to switch workspaces (https://github.com/hyprwm/Hyprland/blob/main/example/hyprland.conf#L158). this just makes the cursor jump around all the time when scrolling

[memchr]

and just focus on the window under the cursor

This will then break focusurgentorlast and focuscurrentorlast.

[vaxerski]

well, then bring back the old behavior (don't focus on whats under the cursor, don't warp it) and we'll merge that, then think about what to do.

[memchr]

df51c45 warpcursor targets follow_mouse == 1 only

The older iterations of changeWorkspace (commit 5a6d0e9) still focus the window under the cursor because they call simulateMouseMovement directly or indirectly.

• Hyprland/src/managers/KeybindManager.cpp

  Line 910 in 5a6d0e9

  g_pInputManager->simulateMouseMovement();

• https://github.com/hyprwm/Hyprland/blob/5a6d0e9963eaca457a1f91c5ab4c3142c145b646/src/managers/KeybindManager.cpp#L895C40-L895C40

If we were to remove these calls, the window under the cursor would still be focused whenever the user moves the mouse (follow_mouse == 1).

So I don't think it can be avoided, because that's what (follow_mouse == 1) does.

don't warp it

At best I think we could introduce an option (by default on) to disable any mousewarp in changeWorkspace,

don't focus on whats under the cursor

but it is not possible to prevent all focus changes if the user wants to use follow_mouse == 1. This would be more obvious if you had multiple windows open in a workspace.

Per wiki

0 - Cursor movement will not change focus.
1 - Cursor movement will always change focus to the window under the cursor.
2 - Cursor focus will be detached from keyboard focus. Clicking on a window will move keyboard focus to that window.
3 - Cursor focus will be completely separate from keyboard focus. Clicking on a window will not change keyboard focus.

[thejch]

and just focus on the window under the cursor

This will then break focusurgentorlast and focuscurrentorlast.

i am not sure how the old behavior would break those

[memchr]

don't warp it

Done via binds:changeworkspace_warp_cursor. No cursor warping is now the default behaviour.

[MightyPlaza]

I think the best way to handle this is to add an extra arg to the workspace dispatcher to allow disabling the warping on same monitor changes with follow_mouse=1.
Should allow user to pick the intended behavior for each individual change

[vaxerski]

I don't like this approach. I'd rather deal away with the warps entirely (no config)

it was a bad idea from the start, tbh.

A better option would be to make a simulateMouseMovement that cannot change focus, only sends motion events to the current window, use that.

[MightyPlaza]

I don't like this approach. I'd rather deal away with the warps entirely (no config)

same thing I said here: #3205
there is no sane way to restore focus and respect follow_mouse=1

[vaxerski]

the only sane way I see is to restore focus, and just change it if the mouse moves according to follow_mouse

if you already moved the mouse you can hover on whatever you want focused :)

[memchr]

it was a bad idea from the start, tbh.

Removing all the warpCursor() calls would be a pretty thorough change. Hyprland has been moving the cursor to the centre of the (keyboard) focused window for some time. There are a total of 19 direct calls to warpCursorTo all over the place and I have nothing to do with the vast majority of them. So maybe we should do it another time?

---

Anyway the behaviour should now be the same as 5a6d0e9 by default.

This just adds two extra config values.

[vaxerski]

I have pushed what I believe to be the best solution to this.

41e5f40
b884544

[memchr]

Updated. The rest of this MR is unrelated to workspaceChange. And on main, the mouse warp could still be triggered on currently focused window, e.g. if a window is removed from a group but the cursor is on the rest of the group, in this case, a warp would be considered unnecessary by some.

So I will leave this open.