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

Workspace swiching switches workspaces on wrong monitor #25

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

Originally created by @pigmej on GitHub (Sep 7, 2021).

Originally assigned to: @LGUG2Z on GitHub.

  1. Two monitor setup
  2. Set keys to Alt + {number} to switch workspaces
  3. Run few windows on workspace 0 on both screens
  4. Switch to empty workspace 1 on screen 1
  5. Switch to empty workspace 1 on screen 0
  6. Switch to non-empty workspace 0 on screen 0
  7. Try to switch to some workspace on screen 1 where currently focused is empty workspace. It will always switch workspaces on screen 0 from now.

The workaround that I'm aware of is to move any of the windows to screen 1 and then switch workspaces, then everything works.

Not sure how much related is that log but I have found that in the logs:

Sep 07 09:00:29.516  INFO process_event{event=Show(ObjectShow, Window { hwnd: 328938 })}: komorebi::process_event: processed: (hwnd: 328938, title: LGUG2Z/komorebi: A tiling window manager for Windows — Mozilla Firefox, exe: firefox.exe, class: MozillaWindowClass)
Sep 07 09:00:29.519  INFO process_event{event=Show(ObjectShow, Window { hwnd: 263406 })}:focus_monitor{idx=1}: komorebi::window_manager: focusing monitor
Sep 07 09:00:29.520  INFO process_event{event=Show(ObjectShow, Window { hwnd: 263406 })}: komorebi::process_event: processed: (hwnd: 263406, title: New Issue · LGUG2Z/komorebi — Mozilla Firefox, exe: firefox.exe, class: MozillaWindowClass)
Sep 07 09:00:37.513  INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}: komorebi::window_manager: focusing workspace
Sep 07 09:00:37.514  INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:focus_workspace{idx=1}: komorebi::monitor: focusing workspace
Sep 07 09:00:37.529  INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:update_focused_workspace{mouse_follows_focus=true}: komorebi::window_manager: updating
Sep 07 09:00:37.530 ERROR komorebi::process_command: The system could not find the environment option that was entered. (os error 203) komorebi\src\window_manager.rs:389
Sep 07 09:00:37.540 ERROR komorebi::process_event: there is no window
Sep 07 09:00:37.556 ERROR komorebi::process_event: there is no window

All happens both on komorebi master branch and released one.

Originally created by @pigmej on GitHub (Sep 7, 2021). Originally assigned to: @LGUG2Z on GitHub. 1. Two monitor setup 2. Set keys to Alt + {number} to switch workspaces 3. Run few windows on workspace 0 on both screens 4. Switch to empty workspace 1 on screen 1 5. Switch to empty workspace 1 on screen 0 6. Switch to non-empty workspace 0 on screen 0 7. Try to switch to some workspace on screen 1 where currently focused is empty workspace. It will always switch workspaces on screen 0 from now. The workaround that I'm aware of is to move any of the windows to screen 1 and then switch workspaces, then everything works. Not sure how much related is that log but I have found that in the logs: ``` Sep 07 09:00:29.516 INFO process_event{event=Show(ObjectShow, Window { hwnd: 328938 })}: komorebi::process_event: processed: (hwnd: 328938, title: LGUG2Z/komorebi: A tiling window manager for Windows — Mozilla Firefox, exe: firefox.exe, class: MozillaWindowClass) Sep 07 09:00:29.519 INFO process_event{event=Show(ObjectShow, Window { hwnd: 263406 })}:focus_monitor{idx=1}: komorebi::window_manager: focusing monitor Sep 07 09:00:29.520 INFO process_event{event=Show(ObjectShow, Window { hwnd: 263406 })}: komorebi::process_event: processed: (hwnd: 263406, title: New Issue · LGUG2Z/komorebi — Mozilla Firefox, exe: firefox.exe, class: MozillaWindowClass) Sep 07 09:00:37.513 INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}: komorebi::window_manager: focusing workspace Sep 07 09:00:37.514 INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:focus_workspace{idx=1}: komorebi::monitor: focusing workspace Sep 07 09:00:37.529 INFO read_commands:process_command{FocusWorkspaceNumber(1)}:focus_workspace{idx=1}:update_focused_workspace{mouse_follows_focus=true}: komorebi::window_manager: updating Sep 07 09:00:37.530 ERROR komorebi::process_command: The system could not find the environment option that was entered. (os error 203) komorebi\src\window_manager.rs:389 Sep 07 09:00:37.540 ERROR komorebi::process_event: there is no window Sep 07 09:00:37.556 ERROR komorebi::process_event: there is no window ``` All happens both on komorebi master branch and released one.
adam added the enhancement label 2026-01-05 14:47:46 +01:00
adam closed this issue 2026-01-05 14:47:46 +01:00
adam commented 2026-01-05 14:47:46 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Sep 7, 2021):

@pigmej I looked into this and initially I wasn't able to reproduce the issue; when switching focus between monitors using komorebic focus-monitor N and then changing workspace, the workspace switches as expected on the correct monitor.

However, when I tried to focus the empty monitor with the mouse in order to select it as the target for workspace switching I was able to reproduce the behaviour described.

I think what makes most sense in this case is to read the cursor position and use that to infer the current monitor before executing any workspace switch. I've pushed this change to the master branch; let me know how this works out for you!

@LGUG2Z commented on GitHub (Sep 7, 2021): @pigmej I looked into this and initially I wasn't able to reproduce the issue; when switching focus between monitors using `komorebic focus-monitor N` and then changing workspace, the workspace switches as expected on the correct monitor. However, when I tried to focus the empty monitor with the mouse in order to select it as the target for workspace switching I was able to reproduce the behaviour described. I think what makes most sense in this case is to read the cursor position and use that to infer the current monitor before executing any workspace switch. I've pushed this change to the `master` branch; let me know how this works out for you!
adam commented 2026-01-05 14:47:46 +01:00
Author
Owner
Copy Link

@pigmej commented on GitHub (Sep 7, 2021):

Oh yeah, Forgot to mention that I was using mouse to switch the "context". Not the keybinding.

@pigmej commented on GitHub (Sep 7, 2021): Oh yeah, Forgot to mention that I was using mouse to switch the "context". Not the keybinding.
adam commented 2026-01-05 14:47:47 +01:00
Author
Owner
Copy Link

@pigmej commented on GitHub (Sep 7, 2021):

But yeah, I can confirm that this use case works now.

Now need to find why some of my windows are getting lost after some time (I suspect stack-ing to be the problem).

@pigmej commented on GitHub (Sep 7, 2021): But yeah, I can confirm that this use case works now. Now need to find why some of my windows are getting lost after some time (I suspect stack-ing to be the problem).
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#25
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?