[BUG]: Stacked windows are not moved together using `komorebic move` commands

[CtByte]

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.

[LGUG2Z]

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 🤞

[CtByte]

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]

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.

[LGUG2Z]

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

[CtByte]

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.

[LGUG2Z]

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 🤞

[CtByte]

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!

[LGUG2Z]

Mouse moving has also been fixed here: https://github.com/LGUG2Z/komorebi/commit/b68ba2ffcd1c1ba828c595196a863e5d71dfec45

[CtByte]

I confirm, indeed it is 👍