Crash on startup

[naoey]

Hello!

Just wanted to say thank you for building this as I've recently switched over to working on Windows and have sorely missed having a WM like this coming from using yabai on macOS. I've gone through the setup as described in the readme but haven't been able to get komorebi up and running yet.

I attempted to get it started as described in the instructions:

PS C:\Users\naoey> komorebic.exe start
Start-Process komorebi -WindowStyle hidden

However nothing happens after this and on running komorebi.exe state I see this output:

PS C:\Users\naoey> komorebic.exe state
Error: No connection could be made because the target machine actively refused it. (os error 10061)

Location:
    /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\result.rs:1675:27

Attempting to run komorebi.exe directly there appears to be an exception on startup causing the process to terminate:

$env:RUST_BACKTRACE = 'full'; komorebi.exe
Aug 13 11:28:17.651  INFO init: komorebi::window_manager: initialising
The application panicked (crashed).
Message:  removal index (is 1) should be < len (is 0)
Location: library\alloc\src\vec\mod.rs:1385

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 9 frames hidden ⋮
  10: alloc::vec::{{impl}}::remove::assert_failed<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\alloc\src\vec\mod.rs:1385
  11: komorebi::workspace::Workspace::remove_window::h4846824783ba2b6e
      at <unknown source file>:<unknown line>
  12: komorebi::windows_api::WindowsApi::load_workspace_information::h5f9f2afc54eb18e1
      at <unknown source file>:<unknown line>
  13: komorebi::window_manager::WindowManager::init::h5dc04cec6e26d635
      at <unknown source file>:<unknown line>
  14: <crossbeam_channel::flavors::array::Channel<T> as core::ops::drop::Drop>::drop::h0095431d3770ac30
      at <unknown source file>:<unknown line>
  15: std::sys_common::backtrace::__rust_begin_short_backtrace::h53b0089f6784328f
      at <unknown source file>:<unknown line>
  16: std::rt::lang_start::{{closure}}::h945d8ad2027e9b68
      at <unknown source file>:<unknown line>
  17: core::ops::function::impls::{{impl}}::call_once<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\ops\function.rs:280
  18: std::panicking::try::do_call<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:401
  19: std::panicking::try<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:365
  20: std::panic::catch_unwind<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panic.rs:434
  21: std::rt::lang_start_internal<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\rt.rs:34
  22: main<unknown>
      at <unknown source file>:<unknown line>
  23: invoke_main<unknown>
      at d:\a01\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  24: __scrt_common_main_seh<unknown>
      at d:\a01\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  25: BaseThreadInitThunk<unknown>
      at <unknown source file>:<unknown line>
  26: RtlUserThreadStart<unknown>
      at <unknown source file>:<unknown line>

This is running on the current latest master @ c15f1e1.

[LGUG2Z]

Thank you for this detailed report! Are you using multiple monitors by any chance? It looks like this is a bug that I didn't catch because I only use one monitor 😅.

I think you're hitting this call which tries to ensure that Windows are associated with the correct monitor.

Looking a bit further in the stack trace it seems like the issue is with this line which was recently introduced as part of the resizing feature. I think that wrapping this in an if let Some() block should resolve the issue, as remove on Vec does indeed panic when index is out of bounds instead of returning an Option<T> like remove on VecDeque.

I'll @ you in this issue when I'm able to push these changes to a branch for you to try out later today 🤞.

[LGUG2Z]

@naoey https://github.com/LGUG2Z/komorebi/tree/hotfix/multi-monitor-startup-panic

[naoey]

Yes, I do use multiple monitors. Tried this branch out and it started up successfully 👍

Another couple of questions that I had:

1. Is there support for having a startup script similar to the yabairc file we'd use with yabai to set the initial startup configuration? It seemed to be following some default config and tiling every workspace on both screens. I set up the AHK script as well with my desired configuration but none of it seemed to be having any effect. Are there any extra steps to set up the configuration?
2. Is a workspace the same as a a virtual desktop in the Windows multitasking paradigm, i.e. new workspaces created with Win + Ctrl + D?

[LGUG2Z]

Right now the AHK script has to be run manually (either by double clicking it in explorer.exe or running something like Start-Process autohotkey.exe komorebi.ahk -WindowStyle hidden in PowerShell), but it's a good idea to look for it in a common directory (probably ~/.komorebi.ahk and then execute it immediately after komorebi.exe starts listening for messages on its socket. I will open a separate issue to track this.

There is currently no option that allows for a workspace without tiling. I will open a a separate ticket to track this.

Workspaces in komorebi are unrelated to Windows Virtual Desktops; they are implemented as a thin layer on top of the existing DWM by showing and hiding windows programmatically. You have a few options for workspace creation right now:

komorebic.exe ensure workspaces MONITOR_IDX DESIRED_WORKSPACE_COUNT

This is usually run at the start of a config file to ensure the minimum number of workspaces that you want to work with on each monitor.

komorebic.exe focus-workspace WORKSPACE_IDX

This will try to switch to the given workspace index on the active monitor, and if it doesn't exist, it will be created, along with any other required workspace indices on the way. For example, if you only have one workspace (0) on the monitor, and you try to focus workspace index 3, workspaces 1 and 2 will also be created in the process.

I think it's a good idea to have a command that will just append a new workspace on the currently focused monitor (similar to the Win+Ctrl+D behaviour); I'll open a separate ticket to track this.

[LGUG2Z]

@naoey The three enhancements on the referenced issues have been implemented and are on the master branch, you can check the commit messages for the new commands that are now available to create/append a new workspace and to configure or toggle tiling on a workspace. 🎉

[naoey]

That was fast! 😄

Thanks a bunch I'll give it a spin later today.

Workspaces in komorebi are unrelated to Windows Virtual Desktops; they are implemented as a thin layer on top of the existing DWM by showing and hiding windows programmatically. You have a few options for workspace creation right now:

Ah that's where my confusion came from, as I was looking to try and disable tiling on specific Windows 10 virtual desktops. Would love to have that as a feature sometime in the future!