Originally created by @Cynosphere on GitHub (Jul 26, 2024).
Describe the bug
Switching workspaces via taskbar breaks if Explorer has been restarted while komorebi is running.
To Reproduce
Steps to reproduce the behavior:
Open a couple windows
Move some to another workspace
Restart Explorer
Try to navigate to a window on a workspace that isn't the current one
Observed behavior
The selected window shows up on the current workspace and the selected border becomes unresponsive.
Switching workspaces still works and everything existing will be tiled properly. New windows do not get tiled.
Only way to fix is to stop and restart komorebi.
Expected behavior
Selecting the window takes you to the workspace it is on and the border doesn't become unresponsive.
Operating System
OS Name: Microsoft Windows 10 Home
OS Version: 10.0.19045 N/A Build 19045
komorebic check Output
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\User
Looking for configuration files in C:\Users\User
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\User\.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
N/A
Originally created by @Cynosphere on GitHub (Jul 26, 2024).
**Describe the bug**
Switching workspaces via taskbar breaks if Explorer has been restarted while komorebi is running.
**To Reproduce**
Steps to reproduce the behavior:
1. Open a couple windows
2. Move some to another workspace
3. Restart Explorer
4. Try to navigate to a window on a workspace that isn't the current one
**Observed behavior**
The selected window shows up on the current workspace and the selected border becomes unresponsive.
Switching workspaces still works and everything existing will be tiled properly. New windows do not get tiled.
Only way to fix is to stop and restart komorebi.
**Expected behavior**
Selecting the window takes you to the workspace it is on and the border doesn't become unresponsive.
**Operating System**
```
OS Name: Microsoft Windows 10 Home
OS Version: 10.0.19045 N/A Build 19045
```
**`komorebic check` Output**
```
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\User
Looking for configuration files in C:\Users\User
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\User\.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**
N/A
adam
added the bug label 2026-01-05 14:50:44 +01:00
I'm guessing that these class registrations are tied to specific instances of explorer.exe. I'll leave this open if anyone wants to dig, but I guess the general guidance should be that if you restart explorer.exe, you should also restart komorebi.exe.
@LGUG2Z commented on GitHub (Jul 27, 2024):
I don't actually understand any of the code in this module or how COM works 😅
https://github.com/LGUG2Z/komorebi/blob/b5eafc6b9678dd70ef0387f38fc52bc35014a615/komorebi/src/com/mod.rs#L1-L3
I'm guessing that these class registrations are tied to specific instances of `explorer.exe`. I'll leave this open if anyone wants to dig, but I guess the general guidance should be that if you restart `explorer.exe`, you should also restart `komorebi.exe`.
Coming back to this after over half a year, I think that this is a reasonable thing to do if explorer.exe has been killed.
@LGUG2Z commented on GitHub (Jan 23, 2025):
> Only way to fix is to stop and restart komorebi.
Coming back to this after over half a year, I think that this is a reasonable thing to do if `explorer.exe` has been killed.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Cynosphere on GitHub (Jul 26, 2024).
Describe the bug
Switching workspaces via taskbar breaks if Explorer has been restarted while komorebi is running.
To Reproduce
Steps to reproduce the behavior:
Observed behavior
The selected window shows up on the current workspace and the selected border becomes unresponsive.
Switching workspaces still works and everything existing will be tiled properly. New windows do not get tiled.
Only way to fix is to stop and restart komorebi.
Expected behavior
Selecting the window takes you to the workspace it is on and the border doesn't become unresponsive.
Operating System
komorebic checkOutputAdditional context
N/A
@Cynosphere commented on GitHub (Jul 26, 2024):
It only seems to be breaking when using the context menu entry from Winaero Tweaker, since that calls cmd to run taskkill and then launch it.
komorebic logoutput:Restaring Explorer through Task Manager or Process Hacker doesn't cause any breakage.
@LGUG2Z commented on GitHub (Jul 27, 2024):
I don't actually understand any of the code in this module or how COM works 😅
https://github.com/LGUG2Z/komorebi/blob/b5eafc6b9678dd70ef0387f38fc52bc35014a615/komorebi/src/com/mod.rs#L1-L3
I'm guessing that these class registrations are tied to specific instances of
explorer.exe. I'll leave this open if anyone wants to dig, but I guess the general guidance should be that if you restartexplorer.exe, you should also restartkomorebi.exe.@LGUG2Z commented on GitHub (Jan 23, 2025):
Coming back to this after over half a year, I think that this is a reasonable thing to do if
explorer.exehas been killed.