Stuck when focusing an workspace that doesn't have any window.

[lgug2z]

Stuck when focusing an workspace that doesn't have any window.

[crosstyan]

Seems perfect to me. Problem fixed!

[LGUG2Z]

Thank you for this detailed report! I have just spent some time trying to reproduce this issue but I have not been successful.

Could you please share the komorebi.ahk you are using and also your Windows version (Get-ComputerInfo | select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer)?

From the logs, I have traced down the Access is denied error to here, which is called when trying to focus the special Desktop Window when a workspace is empty. I have pushed a branch that addresses this error; it would be great if you could try that and see if it changes the behaviour you are experiencing.

[LGUG2Z]

I think I found the panic 🎉

Message:  attempt to divide by zero
Location: komorebi-core\src\layout.rs:144

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 9 frames hidden ⋮
  10: core::panicking::panic<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\core\src\panicking.rs:50
  11: komorebi_core::layout::Layout::calculate::ha406458b4d9a304c
      at <unknown source file>:<unknown line>
  12: komorebi::workspace::Workspace::update::h65bf8870d2c92ead
      at <unknown source file>:<unknown line>
  13: komorebi::window_manager::WindowManager::init::h07c7d42875dc4c52
      at <unknown source file>:<unknown line>
  14: komorebi::window_manager::WindowManager::restore_all_windows::h6966c89d55a8aaff
      at <unknown source file>:<unknown line>
  15: tracing_core::event::Event::metadata::h548cc0816da38c47
      at <unknown source file>:<unknown line>
  16: komorebi::process_command::<impl komorebi::window_manager::WindowManager>::read_commands::h9a03c573b27a0fe7
      at <unknown source file>:<unknown line>
  17: std::sys_common::backtrace::__rust_begin_short_backtrace::h225ab8fda49906c4
      at <unknown source file>:<unknown line>
  18: <&T as core::fmt::Debug>::fmt::hf247fbb9ac06d8b6
      at <unknown source file>:<unknown line>
  19: alloc::boxed::{{impl}}::call_once<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\alloc\src\boxed.rs:1575
  20: alloc::boxed::{{impl}}::call_once<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\alloc\src\boxed.rs:1575
  21: std::sys::windows::thread::{{impl}}::new::thread_start<unknown>
      at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\sys\windows\thread.rs:56
  22: BaseThreadInitThunk<unknown>
      at <unknown source file>:<unknown line>
  23: RtlUserThreadStart<unknown>
      at <unknown source file>:<unknown line>

@crosstyan Don't worry about trying out that branch that I linked, it won't do anything for this issue. I will work on a separate fix for this.

[crosstyan]

My output from Get-ComputerInfo | select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer

WindowsProductName WindowsVersion OsHardwareAbstractionLayer
------------------ -------------- --------------------------
Windows 10 Pro     2009           10.0.22000.1

the ahk file is the same as this sample.

By the way, I'm using a desktop organize software called fences, which I think is related to the problem.

Thank you again for helping solve this problem.

[crosstyan]

I confirmed that Stardock Fences caused that problem. When I disable Fences, everything runs smoothly.

I have to admit compatibility is tricky to deal with, but maybe it's still worth investigating what caused that incompatibility.

Update: the problem is still existing, but I can switch to an empty workspace and switch back now, but moving to a workspace still cause the problem. (still using the old commit)

[LGUG2Z]

@crosstyan I believe this bug should now be fixed with this commit: a53b2cc

Please pull the latest commit on master (which also now includes panic messages in the logs!) and try it out. I hope it fixes the issue for you 🤞 .