From afdbce3db17827526cc9421fde48104c1e6d2851 Mon Sep 17 00:00:00 2001 From: LGUG2Z Date: Mon, 27 Jan 2025 21:16:38 -0800 Subject: [PATCH] fix(borders): respond to sys foreground winevent w/ border manager event This commit ensures that we emit a dedicated border manager event when WinEvent::SystemForeground is received. The OS can actually be slower than komorebi when it comes to processing changed focus state, and in the border manager we rely on GetForegroundWindow when calculating which the border focus state and color should be. This has previously resulted in a situation where there may be no border with the "focused" color. This should no longer be a problem because even in the situations where the OS is slower than komorebi and is still returning an old HWND from GetForegroundWindow, the new event that we emit to border manager in response to WinEvent::SystemForeground will ensure that the border focus colors get updated. --- komorebi/src/windows_callbacks.rs | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/komorebi/src/windows_callbacks.rs b/komorebi/src/windows_callbacks.rs index 5c3f2a96..4b9121a2 100644 --- a/komorebi/src/windows_callbacks.rs +++ b/komorebi/src/windows_callbacks.rs @@ -115,6 +115,16 @@ pub extern "system" fn win_event_hook( } } + // sometimes the border focus state and colors don't get updated because this event comes too + // slow for the value of GetForegroundWindow to be up to date by the time it is inspected in + // the border manager to determine if a window show have its border show as "focused" + // + // so here we can just fire another event at the border manager when the system has finally + // registered the new foreground window and this time the correct border colors will be applied + if matches!(winevent, WinEvent::SystemForeground) && !has_filtered_style(hwnd) { + border_manager::send_notification(Some(hwnd.0 as isize)); + } + let event_type = match WindowManagerEvent::from_win_event(winevent, window) { None => { tracing::trace!(