[Bug]: Hyprland shortcut setup rejects its existing Lua binding #10657

Activity

1. juliusmarminge commented on Sep 8, 2026

   

   juliusmarminge

   on Sep 8, 2026

   Member

   More actions

   Thanks for the tight repro — this checks out on main.

   What’s going wrong

   Hyprland Lua binds show up in hyprctl -j binds as dispatcher: "__lua" with a numeric callback, not as global + com.t3tools.T3Code:capture-window. CaptureShortcutConfig.checkHyprlandKeys only exempts the latter, so reopening Settings → SnapShots → Change shortcut and keeping Ctrl+Shift+2 fails preview (and would fail apply) with “already used by Hyprland.”

   editCaptureConfig already sees the existing hl.bind(..., hl.dsp.global("…:capture-window")) and correctly decides no file change is needed. The live bind check still runs and rejects our own shortcut. The desktop layer wraps that as a generic DesktopSnapShotSetupError, which is why Advanced is unhelpful. The installed shortcut itself keeps working.

   Confirmed in:

   • apps/desktop/src/snapShot/CaptureShortcutConfig.ts (checkHyprlandKeys, preview + apply)
   • apps/desktop/src/snapShot/captureConfigEdit.ts (unchanged Lua binding already recognized)
   • apps/web/src/components/settings/CaptureShortcutConfig.tsx (generic “Couldn't prepare the changes…” copy)

   Introduced with SnapShots in #8103. Not a duplicate of #10644 (Hyprland animation leftover, different path).

   Status

   Accepted, minor. Workaround: close setup and keep using the existing shortcut, or pick a different unused chord.

   A fix is already up: #10658 (Fixes #10657). It skips the live conflict check only when the Lua config is unchanged; Hyprland .conf installs and changed Lua shortcuts still get checked. No second PR needed — review/merge that one.
2. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   acceptedfeature request acceptedfeature request accepted

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   on Sep 8, 2026
3. juliusmarminge commented on Sep 8, 2026

   

   juliusmarminge

   on Sep 8, 2026

   Member

   More actions

   Thanks for the report — this looks real and the diagnosis matches the code.

   CaptureShortcutConfig.checkHyprlandKeys only ignores a live Hyprland bind when dispatcher === "global" and the arg is ${appId}:capture-window. Lua binds from Hyprland 0.56 show up as dispatcher: "__lua" with a numeric callback, so the app's own

   hl.bind("CTRL + SHIFT + 2", hl.dsp.global("com.t3tools.T3Code:capture-window"))

   is treated as a conflict. That check runs on both preview and apply. editCaptureConfig already treats an unchanged Lua capture bind as a no-op, but the live check fails first. The setup dialog then shows the generic “Couldn't prepare the changes” / DesktopSnapShotSetupError instead of “This shortcut is already set up.”

   This is a minor reopen-setup bug. The installed shortcut still captures. Changing to a different unused shortcut still works. .conf binds are unaffected because they still report as global.

   Introduced in #8103. Not a duplicate of #10644 (animation overlay on the same Hyprland setup).

   A fix is already up in #10658: skip the live Hyprland conflict check when the proposed config is unchanged; still check new or changed shortcuts. That's the right shape — we shouldn't try to decode opaque __lua callback IDs.

   Next step: review / merge #10658 (or apply the same skip-when-unchanged check in CaptureShortcutConfig.preview / apply).
4. juliusmarminge

   closed this as completedin #10658on Oct 18, 2026