starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[BUG]: cycle-workspace seems to use mouse to determine which monitor to affect, rather than focused container/window #247

New Issue
Closed
opened 2026-01-05 14:49:15 +01:00 by adam · 4 comments
adam commented 2026-01-05 14:49:15 +01:00
Owner
Copy Link

Originally created by @BlueDrink9 on GitHub (Sep 28, 2023).

Describe the bug
cycle-workspace seems to use mouse to determine which monitor to affect, rather than focused container/window

To Reproduce
Have >1 workspaces and window on each of two monitors.

Focus a window on the left with mouse on right montior, and cycle-workspace. Right workspace cycles.
Move mouse to hover on left monitor.
Cycle-workspace. The left one now changes.
Move focus to right monitor.
Cycle-workspace. The left one still changes

This happens with default config.

Expected behavior
Seems the workspace should only change on the focused monitor

Operating System etc

Writing issue on phone without connection to pc, will provide if specifically requested

Additional context
Not expecting any quick fixes or anything, just happy to be here. But it seems monitor-related code doesn't have as much visibility for you, so I figured the bug report would be helpful.

I notice cycle-monitor isn't changing window focus to the other either, unsure if it's related or a separate bug.

Originally created by @BlueDrink9 on GitHub (Sep 28, 2023). **Describe the bug** cycle-workspace seems to use mouse to determine which monitor to affect, rather than focused container/window **To Reproduce** Have >1 workspaces and window on each of two monitors. Focus a window on the left with mouse on right montior, and cycle-workspace. Right workspace cycles. Move mouse to hover on left monitor. Cycle-workspace. The left one now changes. Move focus to right monitor. Cycle-workspace. The left one still changes This happens with default config. **Expected behavior** Seems the workspace should only change on the focused monitor **Operating System etc** Writing issue on phone without connection to pc, will provide if specifically requested **Additional context** Not expecting any quick fixes or anything, just happy to be here. But it seems monitor-related code doesn't have as much visibility for you, so I figured the bug report would be helpful. I notice cycle-monitor isn't changing window focus to the other either, unsure if it's related or a separate bug.
adam closed this issue 2026-01-05 14:49:16 +01:00
adam commented 2026-01-05 14:49:16 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Sep 28, 2023):

I think this comes back to the code introduced to address this issue, which may not be appropriate when cycling: https://github.com/LGUG2Z/komorebi/issues/30

@LGUG2Z commented on GitHub (Sep 28, 2023): I think this comes back to the code introduced to address this issue, which may not be appropriate when cycling: https://github.com/LGUG2Z/komorebi/issues/30
adam commented 2026-01-05 14:49:16 +01:00
Author
Owner
Copy Link

@BlueDrink9 commented on GitHub (Sep 28, 2023):

Some extra context reproducing the second issue (cycle monitor not working): it seems to only happen when mouse-follows-focus is disabled. When enabled, it works fine

@BlueDrink9 commented on GitHub (Sep 28, 2023): Some extra context reproducing the second issue (cycle monitor not working): it seems to only happen when mouse-follows-focus is disabled. When enabled, it works fine
adam commented 2026-01-05 14:49:16 +01:00
Author
Owner
Copy Link

@BlueDrink9 commented on GitHub (Sep 28, 2023):

Yeah, using the mouse to determine the focused window seems like an unideal workaround for a keyboard-driven workflow (where the mouse may not have been used to interact with the focused window at all).

What were the technical limitations in place? Do you have enough info to get from currently focused window to a monitor number, and from there do the change workspace based on that monitor number?

I can see that switching monitor without the mouse may be tricky if there is no window on the other monitor

@BlueDrink9 commented on GitHub (Sep 28, 2023): Yeah, using the mouse to determine the focused window seems like an unideal workaround for a keyboard-driven workflow (where the mouse may not have been used to interact with the focused window at all). What were the technical limitations in place? Do you have enough info to get from currently focused window to a monitor number, and from there do the change workspace based on that monitor number? I can see that switching monitor without the mouse may be tricky if there is no window on the other monitor
adam commented 2026-01-05 14:49:16 +01:00
Author
Owner
Copy Link

@BlueDrink9 commented on GitHub (Sep 29, 2023):

For now I'm happy to switch to mff tbh. I see that dragging browser tabs into a new window doesn't cause issues with mff, so I'm happy with that as a workaround

@BlueDrink9 commented on GitHub (Sep 29, 2023): For now I'm happy to switch to mff tbh. I see that dragging browser tabs into a new window doesn't cause issues with mff, so I'm happy with that as a workaround
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#247
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?