A black and tan dachshund who lives along the bottom of the screen, with a
bowl he visits for a snack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Searching $HOME buried real results under game assets and nixos config
files. A missing root is harmless: fd reports it on stderr, which nothing
reads, and still searches the rest at exit 0.
None of them worked. quickshell.nix is back to a8eb767 apart from the
hidden-directory search change, which was a separate request and does
work. Removed: the toggle/grab/compositor-event logging, the grab re-arm,
and the full-screen input mask with its click catcher.
Kept the Battle.net window rule's class match (steam_app_0 was stale, and
the tray-icon rule below it needs the widened match), but its comment no
longer claims to fix the launcher.
Recorded the diagnosis at the focus grab so this doesn't get re-derived:
Hyprland's mouseMoveUnified() destroys the seat grab on any refocus()
while the cursor is over a surface the grab doesn't own, and every window
map/unmap calls refocus(). No user input involved, nothing to suppress.
Real cause of the launcher dying ~1ms after opening. Hyprland's
mouseMoveUnified() destroys the seat grab when it refocuses while the
cursor is over a surface the grab doesn't own, and `refocus` is true for
all 20 CInputManager::refocus() call sites — including every window map
and unmap. Battle.net churns windows continuously, so refocus() fired
over and over and killed the grab unless the cursor happened to be on the
bar. That is also why clicking a bar card "fixed" it.
Expand the input mask to the whole screen while a panel is open, so
accepts() is always true and nothing can tear the grab down. The grab no
longer sees outside clicks, so a MouseArea underneath the panels handles
dismissal. Drop the re-arm: it lost to the next refocus() every time.
Hyprland 0.55.4 CXDGShellProtocol::onPopupDestroy() calls
setGrab(nullptr) unconditionally when the popup owning the xdg-popup grab
dies, without checking that grab is still the installed one. So opening
the launcher while some app holds a grabbing popup steals the seat grab,
that popup gets popup_done, the client destroys it, and its destructor
clears OUR grab — one client round trip later, measured at 1-2ms.
A clear that fast is not a click-outside, so re-arm instead of closing.
The offending popup is gone by then, so the second grab sticks. Capped at
3 tries so a hostile client can't spin it.
The rawEvent gate keyed off launcherPanel.open, but the focus-grab clear
sets open=false before Hyprland's IPC event arrives, so the compositor
event around each clear was filtered out — the log came back empty. Key
off a timestamp instead, and report who holds focus when the grab clears.
