mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
Focusing workspaces quickly moves windows between workspaces #91
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 @tgharib on GitHub (Jun 3, 2022).
I have
Windows+Shift+1bound to focus workspace 1 andWindows+Shift+2to focus workspace 2. If I hold,Windows+Shiftand spam 1 and 2 as quickly as possible, windows in workspace 2 will move to workspace 1 or vice-versa. While this procedure is extreme to reproduce the bug, this bug has happened to me during legitimate usage too.I had the same issue when I was using
Alt+1andAlt+2for my workspace keybinds so the bug is not specific to the key binds.@LGUG2Z commented on GitHub (Jun 3, 2022):
Are you running
komorebiwithwindow-hiding-behaviourset tohideorminimize? I know thathidecan occasionally result in the sort of behaviour that you are describing but I haven't experienced this withminimize(yet).hideis still the default as I'm reluctant to make a major version bump just for this one change, but I think that in the future this entire option should just be removed and the behaviour should default tominimize.@tgharib commented on GitHub (Jun 3, 2022):
window-hiding-behaviouris set to minimize. I am usingv0.1.9which appears to default to minimize. When I switch workspaces, the windows for other workspaces are minimized - not hidden.I went ahead an attached a video reproducing this behavior. I have a notepad in workspace 4 and another notepad in workspace 5 and I am simply focusing workspaces 4 and 5 rapidly. I know the bug appears extreme but I encounter this bug when for example, I focus workspace 2 and then immediately change my mind, to focus workspace 3.
I believe this bug occurs because of this timeline:
So just guessing (I didn't look at any code), I think this bug is a consequence of the slowness from the win32 windows api. I imagine fixing this would involve a painful architecture change, to use an internal tree of windows rather relying on the win32 state of minimized/shown windows.
@LGUG2Z commented on GitHub (Jun 3, 2022):
Looks like I've been working on this so long that I no longer know what I'm talking about. 😅
I think that this is indeed most likely due to a timing issue like you have mentioned between the application's internal state and the events being emitted by the Windows API.
It should be possible to wrap calls that update the currently focused workspace with a debouncer which can be personalized by the user with a CLI command. I will look into this when I have some free time over the next few weeks.
@LGUG2Z commented on GitHub (Jun 7, 2022):
Dumping some logs here from the moment when I was able to trigger this on my machine:
@LGUG2Z commented on GitHub (Jun 7, 2022):
It looks like
SystemMinimizeEnd(associated with the received commandFocusWorkspaceNumber(0)) fires afterFocusWorkspaceNumber(1)has been received, which results in this window restoration happening on workspace 1 instead of workspace 0.I tried blocking the
hideandrestorecalls until it's possible to confirm via another API call that the window has indeed been minimized or restored, but I am still able to reproduce this behaviour:@LGUG2Z commented on GitHub (Feb 12, 2023):
@tgharib Check out this commit, just set
window-hiding-behaviourtocloak:80c98596dd@tgharib commented on GitHub (Feb 13, 2023):
Sweet, I cannot reproduce this bug when
window-hiding-behaviouriscloak. It is still reproducible withminimizethough.@LGUG2Z commented on GitHub (Feb 13, 2023):
Ultimately I think I will keep the
hideandminimizeoptions around to avoid breaking peoples' configurations, but for future releases I will set the default tocloakand encourage its use as this is the same (hidden) mechanism used by Microsoft when switching between virtual desktops and naturally it avoids entire classes of bugs like this one.