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

[AksharP5]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. On Omarchy with Hyprland 0.56.2 and Lua configuration, finish SnapShots setup using Ctrl+Shift+2.
2. Confirm the shortcut captures a window.
3. Reopen Settings > SnapShots > Change shortcut.
4. Keep the existing shortcut and click Review changes.

Expected behavior

Setup recognizes the installed shortcut and shows "This shortcut is already set up." Done should complete without rewriting or reloading the config.

Actual behavior

Review changes fails with "Couldn't prepare the changes. Check Advanced for help." Advanced shows a generic DesktopSnapShotSetupError. The underlying preview rejects the existing shortcut as already used by Hyprland.

Hyprland reports Lua bindings as dispatcher: "__lua" with a numeric callback argument. The existing binding is:

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

CaptureShortcutConfig.checkHyprlandKeys exempts only a global dispatcher with the capture action. It consequently rejects the app's own Lua binding even when editCaptureConfig has already found that no config change is needed. The same check runs again during apply.

Reproduced through the unchanged preview API using the current user config and live hyprctl -j binds, and confirmed in the desktop setup dialog. No config writes are needed to reproduce it.

Impact

Minor bug or occasional failure. Reopening setup fails; the already configured capture shortcut continues to work.

Version or commit

main @ a01b227. Introduced with #8103.

Environment

Omarchy 4 development branch; Hyprland 0.56.2; native Wayland; Lua config in the user bindings file.

Workaround

Close setup and keep using the existing shortcut. Changing to a different unused shortcut still works.

[juliusmarminge]

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.

[juliusmarminge]

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).