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]: move-to-monitor-workspace command doesn't physically move window when target workspace has floating layout #401

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

Originally created by @alex-ds13 on GitHub (Jun 3, 2024).

Describe the bug
Like the title states, if the target monitor to where we are trying to send a window to has a floating layout, the window will be set to floating but will stay on the same monitor, however komorebi thinks it is on the monitor we tried to send it to.

To Reproduce
Steps to reproduce the behavior:

  1. Config Setup with two monitors
  2. Config one workspace on each monitor, workspace on main monitor can be any type except floating, workspace on second monitor has to be floating
  3. Open window on main monitor
  4. Try to send window to second monitor using command komorebic move-to-monitor-workspace 1 0
  5. See bug

Expected behavior
Window should actually move to second monitor and become floating

Screenshots and Videos

Operating System
Provide the output of systeminfo | grep "^OS Name\|^OS Version"

OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22631 N/A Build 22631

komorebic check Output
Provide the output of komorebic check

For example:

KOMOREBI_CONFIG_HOME detected: C:\Users\Alex\.config\komorebi

Looking for configuration files in C:\Users\Alex\.config\komorebi

Found komorebi.json; this file can be passed to the start command with the --config flag

Found C:\Users\Alex\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag

Additional context

Originally created by @alex-ds13 on GitHub (Jun 3, 2024). **Describe the bug** Like the title states, if the target monitor to where we are trying to send a window to has a floating layout, the window will be set to floating but will stay on the same monitor, however komorebi thinks it is on the monitor we tried to send it to. **To Reproduce** Steps to reproduce the behavior: 1. Config Setup with two monitors 2. Config one workspace on each monitor, workspace on main monitor can be any type except floating, workspace on second monitor has to be floating 3. Open window on main monitor 4. Try to send window to second monitor using command `komorebic move-to-monitor-workspace 1 0` 5. See bug **Expected behavior** Window should actually move to second monitor and become floating **Screenshots and Videos** **Operating System** Provide the output of `systeminfo | grep "^OS Name\|^OS Version"` ``` OS Name: Microsoft Windows 11 Pro OS Version: 10.0.22631 N/A Build 22631 ``` **`komorebic check` Output** Provide the output of `komorebic check` For example: ``` KOMOREBI_CONFIG_HOME detected: C:\Users\Alex\.config\komorebi Looking for configuration files in C:\Users\Alex\.config\komorebi Found komorebi.json; this file can be passed to the start command with the --config flag Found C:\Users\Alex\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag ``` **Additional context**
adam added the bug label 2026-01-05 14:50:28 +01:00
adam closed this issue 2026-01-05 14:50:28 +01:00
adam commented 2026-01-05 14:50:29 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jun 4, 2024):

Can you confirm if this is also the case for move-to-named-workspace?

@LGUG2Z commented on GitHub (Jun 4, 2024): Can you confirm if this is also the case for `move-to-named-workspace`?
adam commented 2026-01-05 14:50:29 +01:00
Author
Owner
Copy Link

@alex-ds13 commented on GitHub (Jun 4, 2024):

Can you confirm if this is also the case for move-to-named-workspace?

Yes. The same thing happens for move-to-named-workspace. It also happens with cycle-move-to-monitor and move-to-monitor.

@alex-ds13 commented on GitHub (Jun 4, 2024): > Can you confirm if this is also the case for `move-to-named-workspace`? Yes. The same thing happens for `move-to-named-workspace`. It also happens with `cycle-move-to-monitor` and `move-to-monitor`.
adam commented 2026-01-05 14:50:29 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jun 4, 2024):

Thanks for confirming, this should be fixed now

@LGUG2Z commented on GitHub (Jun 4, 2024): Thanks for confirming, this should be fixed now
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 bug
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#401
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?