mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-09-02 22:07:14 +02:00
[BUG]: When mouse_follows_focus is off, Workspace switching shorcuts fail to respect focused monitor #378
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/komorebi#378
Reference in New Issue
Block a user
Originally created by @rp1231 on GitHub (May 18, 2024).
Describe the bug
When mouse_follows_focus is off, Workspace switching shorcuts fail to respect focused monitor.
The workspace switching shortcuts will work on the monitor that has the mouse rather than the monitor that has the focused window.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The workspace should be switched on the monitor containing the focused window rather than the window containing the mouse.
Operating System
@LGUG2Z commented on GitHub (May 18, 2024):
This is a deliberate behaviour that goes back a few years: https://github.com/LGUG2Z/komorebi/issues/30
Since you'll never be able to switch focus to a monitor with an empty workspace anyway if you don't have mouse follows focus enabled, it may be possible to to wrap the existing behaviour in a mouse follows focus check 🤔
@ksharizard commented on GitHub (May 25, 2024):
Can there be a config option of some sort to replicate the old behaviour? I find it quite annoying to drag my mouse to the monitor that i want to switch workspaces on and the "mouse_follows_focus" option leads to the cursor snapping to the center of the window which can be distracting. Love the work with the WM btw and hope to see great success for your project.
@rp1231 commented on GitHub (Jan 26, 2025):
Is this a wont-fix or has it been implemented?
@LGUG2Z commented on GitHub (Jan 27, 2025):
This is fixed now 🎉
@ksharizard commented on GitHub (Jan 27, 2025):
Hi @LGUG2Z , The issue still persists when testing with the latest komorebi from github actions.
Reproduce:
Clicking with mouse on desired monitor also does not help, as the new window is always spawned on monitor 0.
@LGUG2Z commented on GitHub (Jan 27, 2025):
What you're describing is a separate issue and not one that can be handled by komorebi; the operating system ultimately decides where to spawn new windows, and komorebi can only react to tile them wherever the operating system decides to spawn them. The earliest event komorebi receives is once the window has already been rendered.