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]: Stacked windows are not moved together using komorebic move commands #380

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

Originally created by @CtByte on GitHub (May 18, 2024).

Describe the bug
When stacked windows are moved using the commands, only the top window is moved. The behaviour is slightly different when moving on the same monitor or when moving to an other monitor.

I am using the UltrawideVerticalStack layout.

To Reproduce
Steps to reproduce the behavior (see video):

  1. Have 3 windows open and 2 of them stacked.
  2. Current order: Monitor 1 b, Monitor 1 a, Firefox
  3. Use the komorebic move right command. Monitor 1 a stuck on the left.
  4. Current order: Firefox, Monitor 1 a, Monitor 1 b
  5. Click the stackbar tab of Monitor 1 a. Monitor 1 a jumps to the left.
  6. Current order: Firefox, Monitor 1 b, Monitor 1 a

In case moving to an other monitor, the "stuck" window will not jump under the stackbar when clicking on its tag. An other window (that is not in the stack, Firefox in my example) needs to be focused for that to happen.
But even this does not always work, so it can be tested again if this can be fixed for a single monitor.

Expected behavior
Stacked windows are moved together.

Videos

https://github.com/LGUG2Z/komorebi/assets/165908630/68c5cdaf-c704-4478-81d5-3fd00138c7cc

Operating System

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

komorebic check Output

No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\{UserName}

Looking for configuration files in C:\Users\{UserName}

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

Found C:\Users\{UserName}\.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
When I switch to another workplace and back at step 4 (instead of clicking the tab), the "stuck" window jumps to the correct position like in step 6. The same seems to be true when I change the workspace (where the "stuck" window is) on the multi monitor test.

Originally created by @CtByte on GitHub (May 18, 2024). **Describe the bug** When stacked windows are moved using the commands, only the top window is moved. The behaviour is slightly different when moving on the same monitor or when moving to an other monitor. I am using the UltrawideVerticalStack layout. --- **To Reproduce** Steps to reproduce the behavior (see video): 1. Have 3 windows open and 2 of them stacked. 2. Current order: `Monitor 1 b`, `Monitor 1 a`, `Firefox` 3. Use the `komorebic move right` command. `Monitor 1 a` stuck on the left. 4. Current order: `Firefox`, `Monitor 1 a`, `Monitor 1 b` 5. Click the stackbar tab of `Monitor 1 a`. `Monitor 1 a` jumps to the left. 6. Current order: `Firefox`, `Monitor 1 b`, `Monitor 1 a` In case moving to an other monitor, the "stuck" window will not jump under the stackbar when clicking on its tag. An other window (that is not in the stack, `Firefox` in my example) needs to be focused for that to happen. But even this does not always work, so it can be tested again if this can be fixed for a single monitor. --- **Expected behavior** Stacked windows are moved together. --- **Videos** https://github.com/LGUG2Z/komorebi/assets/165908630/68c5cdaf-c704-4478-81d5-3fd00138c7cc --- **Operating System** ``` OS Name: Microsoft Windows 11 Pro OS Version: 10.0.22631 N/A Build 22631 ``` --- **`komorebic check` Output** ``` No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\{UserName} Looking for configuration files in C:\Users\{UserName} Found komorebi.json; this file can be passed to the start command with the --config flag Found C:\Users\{UserName}\.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** When I switch to another workplace and back at `step 4` (instead of clicking the tab), the "stuck" window jumps to the correct position like in `step 6`. The same seems to be true when I change the workspace (where the "stuck" window is) on the multi monitor test.
adam added the bug label 2026-01-05 14:50:11 +01:00
adam closed this issue 2026-01-05 14:50:11 +01:00
adam commented 2026-01-05 14:50:12 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (May 18, 2024):

I'm not able to reproduce this exactly but I do have some jank when using the mouse instead of the hotkeys.

Since the hotkeys work for now I'm gonna leave this open until I can split out the stackbar into its own module like I did for the borders and see if this is one of the those edge cases that gets fixed by the more isolated design 🤞

@LGUG2Z commented on GitHub (May 18, 2024): I'm not able to reproduce this exactly but I do have some jank when using the mouse instead of the hotkeys. Since the hotkeys work for now I'm gonna leave this open until I can split out the stackbar into its own module like I did for the borders and see if this is one of the those edge cases that gets fixed by the more isolated design 🤞
adam commented 2026-01-05 14:50:12 +01:00
Author
Owner
Copy Link

@CtByte commented on GitHub (May 18, 2024):

I could not always reproduce this exactly either, but let's see what comes up when you get the time to make the stackbar module 🤞

@CtByte commented on GitHub (May 18, 2024): I could not always reproduce this exactly either, but let's see what comes up when you get the time to make the stackbar module 🤞
adam commented 2026-01-05 14:50:12 +01:00
Author
Owner
Copy Link

@CtByte commented on GitHub (May 18, 2024):

I am running the monitor-madness branch and I do not think that I saw this issue when I ran the main a while back, but I could be wrong.

I have the feeling that the stackbar used to hide stacked windows that were not visible (behind the focused tab). Almost like when you change between workspaces.

@CtByte commented on GitHub (May 18, 2024): I am running the `monitor-madness` branch and I do not think that I saw this issue when I ran the `main` a while back, but I could be wrong. I have the feeling that the stackbar used to hide stacked windows that were not visible (behind the focused tab). Almost like when you change between workspaces.
adam commented 2026-01-05 14:50:12 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (May 19, 2024):

I think this is fixed on the stackbar manager branch now 🤞

@LGUG2Z commented on GitHub (May 19, 2024): I think this is fixed on the stackbar manager branch now 🤞
adam commented 2026-01-05 14:50:12 +01:00
Author
Owner
Copy Link

@CtByte commented on GitHub (May 19, 2024):

I tried out the stackbar-manager branch and when I only use the hotkeys it seems to be fine even when I move stacks to another monitor and cycle through tabs.

Once I click the tabs it behaves differently, similar to what I described as hidden stacked windows being stuck and the stack being scattered around 2 monitors.

I am also getting this error in the console when I am clicking the tabs (after moving the stack to another monitor):

(not sure how much of the logs I should grab)

[...]

2024-05-19T12:12:21.983119Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 394850 })}: komorebi::process_event: processed: (hwnd: 394850, title: Monitor 1 B, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)
2024-05-19T12:12:21.990523Z  INFO process_event{event=Uncloak(ObjectUncloaked, Window { hwnd: 132920 })}: komorebi::process_event: processed: (hwnd: 132920, title: Monitor 1 A, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS)
2024-05-19T12:12:22.002761Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 132920 })}:focus_monitor{idx=1}:
 komorebi::window_manager: focusing monitor
2024-05-19T12:12:22.003171Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 132920 })}:focus_window{idx=0}: komorebi::container: focusing window
2024-05-19T12:12:22.004547Z  INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 132920 })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating
2024-05-19T12:12:22.005305Z ERROR komorebi::process_event:
   0: there is no container/window

Location:
   komorebi\src\workspace.rs:445

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 11 frames hidden ⋮
  12: komorebi::workspace::impl$1::focus_container_by_window::closure$0<unknown>
      at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\workspace.rs:445
  13: enum2$<core::option::Option<usize> >::ok_or_else<usize,eyre::Report,komorebi::workspace::impl$1::focus_container_by_window::closure_env$0><unknown>
      at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97\library\core\src\option.rs:1231
  14: komorebi::workspace::Workspace::focus_container_by_window<unknown>
      at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\workspace.rs:443
  15: komorebi::window_manager::WindowManager::process_event<unknown>
      at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\process_event.rs:262
  16: komorebi::process_event::listen_for_events::closure$0<unknown>
      at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\process_event.rs:45
  17: core::hint::black_box<unknown>
      at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97\library\core\src\hint.rs:334
                                ⋮ 12 frames hidden ⋮

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
Run with RUST_BACKTRACE=full to include source snippets.
Warning: SpanTrace capture is Unsupported.
Ensure that you've setup a tracing-error ErrorLayer and the semver versions are compatible
2024-05-19T12:12:22.071714Z  INFO komorebi::workspace_reconciliator: focusing alt-tabbed window

[...]

And when I use the hotkey cycle-stack command instead of clicking the tabs, the scattered stack recovers.

So I am guessing there is something done differently when the command is used and when the mouse is used.

@CtByte commented on GitHub (May 19, 2024): I tried out the `stackbar-manager` branch and when I only use the hotkeys it seems to be fine even when I move stacks to another monitor and cycle through tabs. Once I click the tabs it behaves differently, similar to what I described as hidden stacked windows being stuck and the stack being scattered around 2 monitors. I am also getting this error in the console when I am clicking the tabs (after moving the stack to another monitor): (not sure how much of the logs I should grab) ``` [...] 2024-05-19T12:12:21.983119Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 394850 })}: komorebi::process_event: processed: (hwnd: 394850, title: Monitor 1 B, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS) 2024-05-19T12:12:21.990523Z INFO process_event{event=Uncloak(ObjectUncloaked, Window { hwnd: 132920 })}: komorebi::process_event: processed: (hwnd: 132920, title: Monitor 1 A, exe: WindowsTerminal.exe, class: CASCADIA_HOSTING_WINDOW_CLASS) 2024-05-19T12:12:22.002761Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 132920 })}:focus_monitor{idx=1}: komorebi::window_manager: focusing monitor 2024-05-19T12:12:22.003171Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 132920 })}:focus_window{idx=0}: komorebi::container: focusing window 2024-05-19T12:12:22.004547Z INFO process_event{event=FocusChange(SystemForeground, Window { hwnd: 132920 })}:update_focused_workspace{follow_focus=true trigger_focus=false}: komorebi::window_manager: updating 2024-05-19T12:12:22.005305Z ERROR komorebi::process_event: 0: there is no container/window Location: komorebi\src\workspace.rs:445 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ⋮ 11 frames hidden ⋮ 12: komorebi::workspace::impl$1::focus_container_by_window::closure$0<unknown> at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\workspace.rs:445 13: enum2$<core::option::Option<usize> >::ok_or_else<usize,eyre::Report,komorebi::workspace::impl$1::focus_container_by_window::closure_env$0><unknown> at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97\library\core\src\option.rs:1231 14: komorebi::workspace::Workspace::focus_container_by_window<unknown> at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\workspace.rs:443 15: komorebi::window_manager::WindowManager::process_event<unknown> at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\process_event.rs:262 16: komorebi::process_event::listen_for_events::closure$0<unknown> at D:\Workspaces\git\LGUG2Z\komorebi\komorebi\src\process_event.rs:45 17: core::hint::black_box<unknown> at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97\library\core\src\hint.rs:334 ⋮ 12 frames hidden ⋮ Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering. Run with RUST_BACKTRACE=full to include source snippets. Warning: SpanTrace capture is Unsupported. Ensure that you've setup a tracing-error ErrorLayer and the semver versions are compatible 2024-05-19T12:12:22.071714Z INFO komorebi::workspace_reconciliator: focusing alt-tabbed window [...] ``` And when I use the hotkey `cycle-stack` command instead of clicking the tabs, the scattered stack recovers. So I am guessing there is something done differently when the command is used and when the mouse is used.
adam commented 2026-01-05 14:50:13 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (May 19, 2024):

0140e8aba7

I tried reproducing both of the issues you described after making some changes in the commit above and everything looks okay to me now; no cross-monitor move errors or rendering of windows in old positions on my end 🤞

@LGUG2Z commented on GitHub (May 19, 2024): https://github.com/LGUG2Z/komorebi/commit/0140e8aba79a41399d61fbb9c8ec006abf2517e4 I tried reproducing both of the issues you described after making some changes in the commit above and everything looks okay to me now; no cross-monitor move errors or rendering of windows in old positions on my end 🤞
adam commented 2026-01-05 14:50:13 +01:00
Author
Owner
Copy Link

@CtByte commented on GitHub (May 19, 2024):

I tried to test it in every possible way I could think of and it worked. 🎉

I moved the stack and clicked the tabs with mouse only, command only and a mix of the two.

The only thing I could not do is moving the stack by mouse on the same monitor to swap places with another window. When I move a none stacked window to swap places with a stack that worked.

https://github.com/LGUG2Z/komorebi/assets/165908630/7c7d0211-7326-4774-aa5c-3e0426de4d3e

It can be that I am just clumsy, but I would consider this to be a win.

Thank you for taking the time!

@CtByte commented on GitHub (May 19, 2024): I tried to test it in every possible way I could think of and it worked. 🎉 I moved the stack and clicked the tabs with mouse only, command only and a mix of the two. The only thing I could not do is moving the stack by mouse on the same monitor to swap places with another window. When I move a none stacked window to swap places with a stack that worked. https://github.com/LGUG2Z/komorebi/assets/165908630/7c7d0211-7326-4774-aa5c-3e0426de4d3e It can be that I am just clumsy, but I would consider this to be a win. Thank you for taking the time!
adam commented 2026-01-05 14:50:13 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (May 19, 2024):

Mouse moving has also been fixed here: b68ba2ffcd

@LGUG2Z commented on GitHub (May 19, 2024): Mouse moving has also been fixed here: https://github.com/LGUG2Z/komorebi/commit/b68ba2ffcd1c1ba828c595196a863e5d71dfec45
adam commented 2026-01-05 14:50:13 +01:00
Author
Owner
Copy Link

@CtByte commented on GitHub (May 19, 2024):

I confirm, indeed it is 👍

@CtByte commented on GitHub (May 19, 2024): I confirm, indeed it is 👍
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#380
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?