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.
The Battle.net window rule didn't fix the launcher dying on open, so log
Hyprland's own event stream between `launcher toggle -> open` and
`focusgrab cleared` to see what actually takes focus. Gated on a panel
being open. Diagnostic — remove once the cause is known.
Battle.net now maps as steam_app_default, not steam_app_0, so the
suppress_event rule stopped applying — its activation spam clears
quickshell's focus grab, which kills the launcher in the same frame it
opens. Match either class; same for the tray-icon rule.
fd drops --hidden, so ~/.cache, ~/.local/share/Steam, .git trees and
friends are out of the search entirely — most of the files under $HOME
and none of them worth matching by name. The .git/.cache/.steam excludes
go with it; node_modules is the one junk tree that isn't hidden.
Also log the three points that can swallow a Super+R: the IPC handler
when no bar is registered, the toggle itself, and the focus grab closing
a panel the user didn't close. journalctl --user -u quickshell.
The results ListView had add/remove transitions animating opacity and
scale on the delegate root. The model is re-diffed on every keystroke, so
a row part-way through a fade frequently survived the next pass as a move
instead of a remove — and move animates x,y only, leaving the
half-finished opacity permanently unrestored. Rows accumulated stuck at
arbitrary opacities depending on typing speed, which read as the result
colours randomly fading.
Dropped both fades. x,y stay animated because the view re-asserts them on
every layout, so an interrupted slide self-corrects; opacity and scale
have no such backstop. Comment records that a future fade belongs on a
child item, not the root the view recycles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
launchPin passed a bare DesktopEntry to activate(), but activate()
started dispatching on a `kind` field when the results list became
heterogeneous (apps + files + web). A bare entry has no `kind`, so every
pin click fell through to the no-op branch: the tiles rendered, hovered
and dragged correctly and simply never launched. Regression from
"launcher searches files and the web".
Wrap via appItem() so the pin takes the same path as a search result, and
make activate()'s fallthrough console.warn instead of returning quietly —
the silence is the only reason this survived a release.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Profiled the second model call visible in modelUsage: it is
`source=generate_session_title`, inventing a title for a session that
--no-session-persistence immediately discards. It costs no wall time —
both requests dispatch ~1ms apart and run concurrently, which is why
duration_api_ms was roughly double duration_ms — but it spent 507 input
tokens against 153 for the actual question.
--name qs-ask removes it: one request instead of two, 660 input tokens
down to 153 per question. No latency change, 77% less input token spend,
which is what actually matters when the budget is a subscription rate
limit rather than a bill.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Profiled where the ~6s actually went, and it was not where I assumed.
Haiku defaults to extended thinking, so it spent 225 output tokens and
1.9s deliberating before emitting an 80-character answer about the height
of a tower. MAX_THINKING_TOKENS=0: 43 output tokens, time-to-first-text
2657ms -> 1122ms, wall clock 5.7s -> ~2.4s, answer unchanged.
Two things measured NOT to be the bottleneck, recorded in the comment so
nobody optimises them later: process startup (0.12s boot plus 28ms to
fire the request, so a warm/persistent process saves nothing) and prompt
size (184 input tokens, no bloat to trim).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
