[BUG]: Unexpected behavior after enabling monocle mode on a window stack

[RaptDept]

[BUG]: Unexpected behavior after enabling monocle mode on a window stack

[LGUG2Z]

Repro'd by myself and @raggi earlier this week, but I can't remember if this was fixed on master or not yet.

[raggi]

I believe this is #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]

Closing as a dupe, will track work on #758