quickshell: drop redundant keyring unlock, pam already does it in auth

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
rope 2026-08-23 19:55:10 +01:00
parent 888eedad39
commit ca63bc9544
2 changed files with 27 additions and 54 deletions

View file

@ -329,13 +329,12 @@ in
hl.exec_cmd("wl-paste --type image --watch cliphist store")
hl.exec_cmd("hyprctl setcursor Bibata-Modern-Ice 24")
-- Spotify is NOT started here. It asks the Secret Service for its
-- credentials the moment it launches, which at this point is
-- before the lockscreen has been dismissed and therefore before
-- the login keyring is unlocked. Lock.qml unlocks the keyring with
-- --replace, and that kills the daemon spotify would already be
-- mid-request with, leaving it stuck half-loaded. So Lock.qml
-- launches it instead, right after the unlock succeeds. The window
-- rule below still swallows it onto special:music, and the
-- credentials the moment it launches, and at this point the
-- lockscreen has not been dismissed yet, so the login keyring is
-- still locked and it lands on gcr's unlock prompt instead of
-- loading. Lock.qml starts it after pam accepts the password
-- (pam_gnome_keyring unlocks the keyring in its auth phase). The
-- window rule below still swallows it onto special:music, and the
-- respawn-on-close rule above is unaffected.
-- Scratchpad terminal: parked on special:scratch at
-- login so SUPER+Return is always an instant toggle and the shell