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

Switch workspace on multiple monitors simultaneously #66

New Issue
Closed
opened 2026-01-05 14:48:02 +01:00 by adam · 3 comments
adam commented 2026-01-05 14:48:02 +01:00
Owner
Copy Link

Originally created by @Vernetzt on GitHub (Dec 3, 2021).

Originally assigned to: @LGUG2Z on GitHub.

Probably more of a question/feature request than bug but is it possible to focus/change a workspace on a monitor that the cursor does not currently reside?

komorebi.ahk.

Run, komorebic.exe focus-follows-mouse disable, , Hide
Run, komorebic.exe mouse-follows-focus disable, , Hide

Run, komorebic.exe ensure-workspaces 0 2, , Hide
Run, komorebic.exe ensure-workspaces 1 2, , Hide

Run, komorebic.exe workspace-name 0 0 ws1, , Hide
Run, komorebic.exe workspace-name 0 1 ws2, , Hide
Run, komorebic.exe workspace-name 1 0 ws1, , Hide
Run, komorebic.exe workspace-name 1 1 ws2, , Hide

My first thought was that this would do the trick

komorebic.exe focus-monitor 1
komorebic.exe focus-workspace 1

But this will only change the workspace on monitor 0 or more specifically where the cursor resides.

By setting focus-follows-mouse and mouse-follows-focus to disable I assumed that would allow for this functionality but it seems I could be wrong.
Possibly related to #30 / 2a4e6fa6dac8dc91c18b6939ccdf5408af4a4142?

Windows 11 - 22000.348
komorebi built from master (as of 85fe20ebba)

Originally created by @Vernetzt on GitHub (Dec 3, 2021). Originally assigned to: @LGUG2Z on GitHub. Probably more of a question/feature request than bug but is it possible to focus/change a workspace on a monitor that the cursor does not currently reside? komorebi.ahk. ``` Run, komorebic.exe focus-follows-mouse disable, , Hide Run, komorebic.exe mouse-follows-focus disable, , Hide Run, komorebic.exe ensure-workspaces 0 2, , Hide Run, komorebic.exe ensure-workspaces 1 2, , Hide Run, komorebic.exe workspace-name 0 0 ws1, , Hide Run, komorebic.exe workspace-name 0 1 ws2, , Hide Run, komorebic.exe workspace-name 1 0 ws1, , Hide Run, komorebic.exe workspace-name 1 1 ws2, , Hide ``` My first thought was that this would do the trick ``` komorebic.exe focus-monitor 1 komorebic.exe focus-workspace 1 ``` But this will only change the workspace on monitor 0 or more specifically where the cursor resides. By setting `focus-follows-mouse` and `mouse-follows-focus` to `disable` I assumed that would allow for this functionality but it seems I could be wrong. Possibly related to #30 / 2a4e6fa6dac8dc91c18b6939ccdf5408af4a4142? Windows 11 - 22000.348 komorebi built from master (as of 85fe20ebba4fd5832f233efb75372ce4f5644ebf)
adam added the enhancement label 2026-01-05 14:48:02 +01:00
adam closed this issue 2026-01-05 14:48:02 +01:00
adam commented 2026-01-05 14:48:02 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Dec 3, 2021):

I have just tested this out and for the behaviour I think that you are looking for, it works if mouse-follows-focus is enabled, but it only works if there is something visible on the monitor that you are trying to change the focused workspace on, so, your example wouldn't work if the current workspace on monitor 1 had no windows, because the focus-monitor command would not move the cursor to monitor 1 and so the focus-workspace command would run on the previously focused monitor.

I will look into creating a dedicated focus command that allows users to pass both the monitor index and the workspace index of that monitor, bypassing the cursor position constraint in the individual workspace focus command.

@LGUG2Z commented on GitHub (Dec 3, 2021): I have just tested this out and for the behaviour I think that you are looking for, it works if `mouse-follows-focus` is enabled, but it only works if there is something visible on the monitor that you are trying to change the focused workspace on, so, your example wouldn't work if the current workspace on monitor 1 had no windows, because the `focus-monitor` command would not move the cursor to monitor 1 and so the `focus-workspace` command would run on the previously focused monitor. I will look into creating a dedicated focus command that allows users to pass both the monitor index and the workspace index of that monitor, bypassing the cursor position constraint in the individual workspace focus command.
adam commented 2026-01-05 14:48:02 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Dec 3, 2021):

@Vernetzt Please check out this commit and see how that new command works for you: 1ae0a3bf74

@LGUG2Z commented on GitHub (Dec 3, 2021): @Vernetzt Please check out this commit and see how that new command works for you: https://github.com/LGUG2Z/komorebi/commit/1ae0a3bf74d679d9347d84e4983952c3e665962b
adam commented 2026-01-05 14:48:02 +01:00
Author
Owner
Copy Link

@Vernetzt commented on GitHub (Dec 3, 2021):

Running focus-monitor-workspace seems to work great so far and I haven't run into any unwanted results or errors as of yet.

Thanks the quick response and solution. Finding a window manager that suits all of my needs on Windows has been a nearly impossible task so stumbling across this has been a nice surprise. Especially with the possibility of two features I use heavily with my own AHK scripts being looked into. (57 and 34) 42 is also pretty great.

I appreciate the project, thanks!

@Vernetzt commented on GitHub (Dec 3, 2021): Running `focus-monitor-workspace` seems to work great so far and I haven't run into any unwanted results or errors as of yet. Thanks the quick response and solution. Finding a window manager that suits all of my needs on Windows has been a nearly impossible task so stumbling across this has been a nice surprise. Especially with the possibility of two features I use heavily with my own AHK scripts being looked into. ([57](https://github.com/LGUG2Z/komorebi/issues/57) and [34)](https://github.com/LGUG2Z/komorebi/issues/34) [42](https://github.com/LGUG2Z/komorebi/issues/42) is also pretty great. I appreciate the project, thanks!
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 enhancement
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#66
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?