mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[BUG]: Workspace switching loop #411
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Insprill on GitHub (Jun 14, 2024).
Describe the bug
When focusing an application in another workspace, it will sometimes get stuck in an infinite workspace-switching loop that can only be stopped by killing komorebi and the application via task manager. It would appear that
07b2da69a1didn't fully fix the issue. It's quite rare now; I've only had it happen twice in the last three weeks when Unity focuses on Rider (something that happens at least 50 times a day for me) but it does still happen.To Reproduce
*see additional context
Expected behavior
Komorebi should not get stuck in a workspace-switching loop.
Operating System
komorebic checkOutputAdditional context
I've only had this happen when Unity focuses Rider (e.g., when opening a script), so it's possible the issue lies somewhere in there, but I find it more likely it's a general issue that only shows itself there due to how often that happens.
@LGUG2Z commented on GitHub (Jun 14, 2024):
I think this will ultimately require some tuneable configuration parameters that can be set by the user, but for now when you do get hit with this bug you can probably hit alt-p to komorebic pause to get out of the loop
@LGUG2Z commented on GitHub (Jun 19, 2024):
8bf4ab9f15This may have some impact on this issue
@melMass commented on GitHub (Jul 20, 2024):
I'm experiencing this in a very reproducible manner with HoudiniFX (3D VFX QT application), I'll try Alt+P next time as only killing Komorebi works for now
@rwijtvliet commented on GitHub (Nov 22, 2024):
I'm very regularly experiencing this when restarting komorebi and (manually) redistributing the windows over the various workspaces. I invariably reach a point where it will start looping through the workspaces, though I have not found a way to reliably reproduce. If it helps, the applications that are usually open are wezterm, outlook, edge, teams.
@LGUG2Z commented on GitHub (Nov 22, 2024):
Curious to know why setting
initial_workspace_rulesfor the apps you always want to move to different workspaces on restart isn't an option 👀@rwijtvliet commented on GitHub (Nov 22, 2024):
Ah, I actually have those in place normally. I just temporarily removed them, because I thought they might be causing the issue. But turns out, the issue also arises when they are absent.
@rwijtvliet commented on GitHub (Nov 25, 2024):
Is there something I can do to help find the issue?
@rwijtvliet commented on GitHub (Dec 3, 2024):
I recorded the output of
komorebiduring one of the loops, maybe it is helpful in finding the source. Here is one second's worth:@rwijtvliet commented on GitHub (Dec 3, 2024):
This may be helpful: on my machine a loop seems to only appear when multiple monitors are connected! They all show the same image. (the internal laptop monitor and 2 additional external ones).
I have not yet observed a loop if no external monitors are connected.
In the output above, I see several lines targeting distinct monitors - that might be a hint too. (
focus_monitor{idx=2}: komorebi::window_manager: focusing monitor, but also withidx=1andidx=0.)@melMass commented on GitHub (Dec 3, 2024):
Dual monitor user too in case it matters!
@f34r1335 commented on GitHub (Feb 12, 2025):
This might not be the exact same, but I had a slightly similar issue where the windows kept shuffling non stop in a loop. You can test this with
"window_hiding_behaviour": "Minimize"and"window_container_behaviour": "Append"in the config and try stacking some windows together more detail in my other thread if interested.