-
-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stuck when focusing an workspace that doesn't have any window. #2
Comments
Noticed in the logs when looking at issue #2 that an "Access is denied. (os error 5)" error was being reported when trying to attach to the thread of the special Desktop Window, which only happens when switching to a workspace which doesn't contain any windows. Calling WindowsApi::set_foreground_window on the HWND directly seems to be the better option here. re #2
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 From the logs, I have traced down the |
I think I found the panic 🎉
@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. |
My output from WindowsProductName WindowsVersion OsHardwareAbstractionLayer
------------------ -------------- --------------------------
Windows 10 Pro 2009 10.0.22000.1 the 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. |
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) |
Noticed in the logs when looking at issue #2 that an "Access is denied. (os error 5)" error was being reported when trying to attach to the thread of the special Desktop Window, which only happens when switching to a workspace which doesn't contain any windows. Calling WindowsApi::set_foreground_window on the HWND directly seems to be the better option here.
While investigating issue #2 I was able to reproduce it and view the panic that causes the komorebi process to become non-responsive. When switching to a columnar layout (which is the default for the 2nd workspace in the sample ahk config), there is the possibility to cause a divide by zero panic if the len passed to Layout::calculate is 0. I have remedied this by changing the type of len from usize to NonZeroUsize, and also by ensuring that Layout::calculate is only called from within the komorebi crate if the workspace has at least one container. While moving containers around I also noticed that creating a new container for a window may also cause a panic if focused_idx + 1 is greater than the length of the VecDeque of containers, so this was addressed by pushing to the back of the VecDeque in that case. re #2
The two bugs raised in issues #1 and #2 were due to panics that were not visible in the logs, which left the process hanging and unresponsive, ultimately needing to be force killed with a command like 'Stop-Process -Name komorebi'. The only way to even verify that a panic had taken place and what the panic related to, was to run '$env:RUST_BACKTRACE ='full'; komorebi.exe', wait for the panic, then restore the now-hidden window with 'komorebic restore-windows' to finally see the panic message. This commit integrates an example from the 'tracing' repo, which through the addition of a panic hook, logs out panics as errors. Hopefully this will debugging much easier in the future. re #1, re #2
@crosstyan I believe this bug should now be fixed with this commit: a53b2cc Please pull the latest commit on |
Seems perfect to me. Problem fixed! |
First of all, thank you for this wonderful window manager. I switched from workspacer and I'm a fan of bspwm.
Here is the problem. I created workspaces by
I think the default workspace is
0
. if I switch to an empty workspace byThe komorebi window manager stop working. New window won't get tilted and I can't switch back by
komorebic focus-workspace 0
. Besides, there's no output when usingkomorebic state
. I can get missing windows byrestore-windows
though.But it works pretty well if I moved a window to that workspace first. If I use
to move focused window to workspace 1. The problem won't appear. ( I still get stuck when I switch to an empty workspace like 2 or 3 though)
Here is log in
~/komorebi.log
The text was updated successfully, but these errors were encountered: