Background: KWin currently supports focus-follows-mouse, but there is no built-in option to also move the pointer automatically to the newly focused window when focus changes via keyboard actions such as Alt+Tab, window shortcuts, or task switcher navigation. This feature was requested previously in Bug #37719, and was closed RESOLVED INTENTIONAL. The rationale at the time was that programmatically moving the pointer is undesirable and can surprise users. Why the request should be reconsidered: The use case for this feature has become significantly more relevant due to modern workflows and compositor expectations: - Many users now run hybrid workflows mixing mouse and keyboard navigation. - Alt+Tab is significantly less usable with focus-follows-mouse because the pointer remains on the previous window. - Several modern compositors (e.g., Hyprland) implement this behavior by default and it works reliably. - On Wayland, some applications and compositors already accept pointer warping in specific contexts (e.g., popup focus)? Proposed behavior: - Add an explicit, opt-in setting in KWin: “Mouse follows focus (warp pointer on focus change)” -When enabled: - Focus-follows-mouse and click-to-focus remains unchanged. - When focus changes via keyboard or programmatic means (Alt+Tab, keyboard window switch, task switcher, activity switch, etc.), the pointer is warped to a deterministic location (e.g., center) of the newly focused window. This should be implemented in a way that avoids the issues described in Bug 37719: - Only warp on focus changes initiated by keyboard or programmatic actions, not on every mouse-enter event. - Avoid “pointer trapping” by not warping on transient focus changes (e.g., tooltip hover)? - Make it clear and reversible in System Settings. Safety and UX: - Make the option must be disabled by default. Benefits: - Restores usability of Alt+Tab in focus-follows-mouse mode (Alt+Tab is kind of pointless with focus-follows-mouse otherwise). - Improves hybrid workflows (mouse + keyboard) without changing default behavior. - Reduces reliance on third-party scripts (I don't think there are currently any for Wayland at this time actually). - Aligns KWin with modern compositor expectations.
The problem is that we already have too many focus modes (that we even need to provide helper text to explain what they do), and adding more won't help us. That big number of focus modes prevented us from implementing some wayland protocols because the relevant code is not easy to work with. So rather than adding a new mode or options, I'd suggest that you write a script to achieve this. You can query the current pointer position, I believe you can't warp the pointer but APIs can be added for that (and other missing bits).
After some more reading, I discovered that KWin already has an internal implementation for pointer centering via the default Meta+F5 shortcut ("Move Mouse to Focus"), which centers the mouse on the currently focused window. That code path clearly has access to pointer warping, window geometry, and the relevant input backend, so the underlying capability already exists. Rather than pursuing a KWin script solution (which doesn't support pointer warping, as you stated), would it be feasible to reuse that existing internal mechanism selectively for keyboard-induced focus changes, such as when focus is finalized via the the keyboard (i.e., Alt+Tab task switcher and "Switch to Window" shortcuts)? I imagine this should be gated by focus reason and not applied to all focus changes, as in, applied: - Only after focus changes initiated by the keyboard - Never for pointer-driven focus (hover, click) - Opt-in, disabled by default Conceptually, this seems closer to “pointer centering after keyboard window activation” than traditional mouse-follows-focus behavior, and avoids pointer/focus feedback loops. From the user side, this would mirror the existing "Move Mouse to Focus" (Meta+F5) behavior, just automatically invoked at a well-defined internal point (e.g., task switcher/switch-to-window focus), rather than on every activation. Would this approach be acceptable architecturally?