[BUG] Disabling Quick capture hotkey does not persist across restart on Linux (Gnome)

[scottames]

tl;dr: The disabled preference persists and ZenNotes correctly displays "Disabled" after restart. However, startup still registers the default shortcut with the Wayland global-shortcuts portal, opening GNOME Settings' "Add Keyboard Shortcuts" window (org.gnome.Settings.GlobalShortcutsProvider) on every app launch.

Context: ZenNotes v2.28.2 installed from RPM on Fedora with Niri/Wayland and GNOME's xdg-desktop-portal backend installed.

Steps to reproduc

1. Start ZenNotes on a Wayland session.
2. Open Settings > Editor > Quick capture and click Disable for Quick capture hotkey.
3. Quit ZenNotes and start it again.

Actual behavior

ZenNotes continues to display the persisted preference as "Disabled" after restart. Separately, its startup path substitutes CommandOrControl+Shift+Space for the empty disabled value and registers that shortcut with the system. With Electron's GlobalShortcutsPortal enabled, this invokes the desktop portal and opens GNOME Settings' "Add Keyboard Shortcuts" window, which shows Ctrl+Shift+Space for ZenNotes.

Expected behavior

The disabled state should prevent global-shortcut registration. ZenNotes should not invoke the global-shortcuts portal after the user disables it.

Likely cause

The empty string is intentionally the persisted disabled value, and registerQuickCaptureHotkey("") correctly skips registration. However, startup keeps the stored preference unchanged while replacing it with the default only for registration through:

const desired = cfg.quickCaptureHotkey || DEFAULT_QUICK_CAPTURE_HOTKEY;

in apps/desktop/src/main/index.ts. Because "" is falsey, the default shortcut is re-registered after every restart.

Solution/Takeaway: Preserve the explicit empty string when choosing the startup registration value rather than treating it as unset.

[adibhanna]

Fixed in b2313de, shipping in 2.30.0, and your diagnosis was exactly right down to the expression: cfg.quickCaptureHotkey || DEFAULT_QUICK_CAPTURE_HOTKEY treated the persisted empty string as unset. Startup now passes the stored value through unchanged; registerQuickCaptureHotkey("") was already a clean no-op, so a disabled hotkey registers nothing and never touches the global-shortcuts portal. Fresh installs still get the default, and only corrupt non-string values fall back during normalization.

Verified on macOS that a disabled value boots with no registration; the portal dialog itself is Wayland-specific and I could not reproduce it here, so once 2.30.0 reaches you on Fedora I would appreciate a confirmation that launches are quiet. If the dialog still appears, comment and I will reopen.

Thank you for an unusually good report: repro, mechanism, and the fix, all correct.