feat(hotkeys): persistent conflict marker in Settings
A toast is gone by the time the user opens Settings, so a hotkey Windows refused looked perfectly configured while doing nothing. The offending row now carries a ⚠ marker (amber border + tooltip explaining the combo is taken) until a re-registration clears it. Delphi reports slot ids instead of labels; HOTKEY_SLOTS maps id → button + label in one place, so JS owns the wording and can flag the exact row. The markers are re-applied by openSettings, surviving panel re-renders. Also stop toasting success on the startup push (it fires on every unlock) — autofillPushHotkeys(true). A clash still warns: that one is actionable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -2617,6 +2617,16 @@ body[data-editor-position="center"]:has(#settingsPanel.is-open)::before {
|
||||
min-width: 140px;
|
||||
text-align: center;
|
||||
}
|
||||
/* Combo refused by Windows (another app holds it) — the hotkey is dead, so the
|
||||
row has to say so long after the toast is gone. ⚠ via ::after so no markup
|
||||
change is needed when the state flips. */
|
||||
.hotkey-capture-btn.is-conflict {
|
||||
border-color: var(--warning, #e0a800);
|
||||
color: var(--warning, #e0a800);
|
||||
}
|
||||
.hotkey-capture-btn.is-conflict::after {
|
||||
content: " ⚠";
|
||||
}
|
||||
.hotkey-capture-btn.is-capturing {
|
||||
background: var(--accent);
|
||||
color: var(--accent-fg, #fff);
|
||||
|
||||
Reference in New Issue
Block a user