aw-watcher-window` does not track CrossOver/Wine windows on macOS

[jonaskindler93]

Summary

When a CrossOver-hosted (Wine) application is focused — for example, a Windows game running through CrossOver — aw-watcher-window-macos does not emit a new event for it. Instead, the bucket continues to report the previously focused native macOS window for the entire duration I'm in the Wine app. Time spent in Wine apps is therefore attributed to whatever I looked at before switching to them, which is wrong.

Steps to reproduce

1. Launch a Windows application through CrossOver (any bottle).
2. With aw-watcher-window running, switch back and forth between a native macOS app (e.g. Safari) and the CrossOver window a few times, spending several seconds in each.
3. Open the ActivityWatch web UI (or query the aw-watcher-window_<hostname> bucket directly) and look at the events for that time range.

Expected behavior

Events are emitted while the CrossOver window is focused, showing some reasonable app identifier (e.g. CrossOver, the bottle name, or the Wine process name) and the current window title.

Actual behavior

No events are emitted while the CrossOver window is focused. The bucket shows the last native macOS window as if it remained focused the whole time.

Additional context

I wrote a minimal replacement watcher in AppleScript via osascript that uses System Events:

tell application "System Events"
    set frontApp to first application process whose frontmost is true
    set appName to name of frontApp
    tell frontApp
        set windowTitle to value of attribute "AXTitle" of (value of attribute "AXFocusedWindow")
    end tell
    return appName & "|" & windowTitle
end tell

This does capture CrossOver/Wine windows correctly, including the window title set by the Wine-hosted app. So the Accessibility API clearly exposes the information — the current Swift implementation seems to take a code path that doesn't reach it.

Speculation about possible root causes (haven't verified against the source):

• The implementation relies on NSWorkspace.shared.frontmostApplication and a notification-based state that doesn't fire when focus moves to a CrossOver-hosted window.
• It queries only AXMainWindow, which CrossOver-bottled apps may not set; AXFocusedWindow might work where AXMainWindow doesn't.
• It filters processes by bundle identifier / bundle type and excludes CrossOver's wrapper processes.

Happy to test fixes or provide more diagnostic output if useful.

[m13v]

hit this exact issue building a macOS window tracker. the root cause isn't AXMainWindow, it's NSWorkspaceDidActivateApplicationNotification. CrossOver runs as one wrapper process so child window focus changes never fire activation, and any Cocoa-notification-based watcher goes blind. the fix is polling AXUIElementCreateSystemWide + kAXFocusedUIElementAttribute every ~500ms, or subscribing to AXObserverAddNotification on kAXFocusedUIElementChangedNotification per pid. the AppleScript path works because System Events walks AX directly and bypasses the Cocoa layer. same gotcha hits Parallels and some Electron apps with multiple BrowserWindows.