LGUG2Z
commented
7 months ago Repro'd by myself and @raggi earlier this week, but I can't remember if this was fixed on master or not yet.
Closed RaptDept closed 7 months ago
LGUG2Z
commented
7 months ago Repro'd by myself and @raggi earlier this week, but I can't remember if this was fixed on master or not yet.
raggi
commented
7 months ago I believe this is https://github.com/LGUG2Z/komorebi/issues/758
I think the root cause is that now that we're sending ObjectDestroy messages down into process_event now - previously they would error in should_manage, which prevented any of those messages to be passed in at all (relying on reap to cleanup instead). This then raised a pre-existing but not-exercised bug where ObjectDestroy assumes that the object being destroyed is always in the "focsued workspace" / "focused container", which isn't always the case.
This is essentially a whole class of bug around event processing using focused_* to route events. Another example in this class is the "invisible windows still affecting layout", like Discord frequently triggers. (Repro for discord is: open discord, focus another window in another workspace, hit the X on discord without focusing it - Komorebi won't correctly understand what changed, resulting a few different kinds of issue). Another class of this bug is: Open an unmanaged window, e.g. WhatsApp (without extra app definitions), which is layered and ignored. Focus a managed window, then drag whatsapp by title - the managed window will get moved when the drag completes.
As a broad stroke we need to move away from "focused_*" for workspace/containers in event processing, instead we need to look at WindowsApi::foreground_window to get an HWND (which requires retries sometimes if the foreground window is mid-switch), then hunt for that HWND in the containers to perform container modifications. The general notion of "focused container" needs to be kept in sync with WindowsApi::foreground_window (most events will need to check this for result - even ObjectFocus - as I've seen ObjectFocus,SystemForeground come in pointing at the wrong window (e.g. the stackbar windows create these, but never get focused/activated, and when those events arrive WindowsApi::foreground_window shows a different window being focused)). The notion of a focused container will then only be used to implement commands, and never to target or originate externally generated mutations (window drags, alt-tabs, click-to-focus changes, etc).
LGUG2Z
commented
7 months ago Closing as a dupe, will track work on #758
Describe the bug Enabling monocle mode on a stack of windows causes unexpected behavior:
komorebic promotewhile stuck in monocle mode will cause a panic.To Reproduce Steps to reproduce the behavior:
komorebic promotewill cause a panic and komorebi will stop responding (this can also happen in step 3)Expected behavior
komorebic promoteshould probably do nothing but not cause a panic.Screenshots and Videos Add screenshots and videos to help explain your problem.
Operating System
komorebic checkOutputAdditional context