1
0
mirror of https://github.com/AvengeMedia/DankMaterialShell.git synced 2026-06-16 16:15:23 -04:00

fix(lock): dismiss fade-to-lock overlay when using a custom lock command (#2653)

When a custom lock command is configured, Lock.lock() runs the command and
returns early without engaging WlSessionLock, so IdleService.isShellLocked
never transitions true->false. That transition is the only trigger that
dismisses a completed FadeToLockWindow, so the fully-faded black overlay stays
on screen and the desktop is unusable after re-login (regression from b8f4c35,
which added the _completed guard and tied dismissal solely to isShellLocked).

Add a dedicated dismissFadeToLock signal that the custom-lock branch emits
after launching the external locker, mirroring the existing fade signal wiring,
so the overlay is handed off and torn down. The built-in WlSessionLock path is
unchanged and still dismisses on unlock.

Fixes #2595
This commit is contained in:
Rocho
2026-06-16 19:45:28 +02:00
committed by GitHub
parent 2f39f248fc
commit ca1a45ccf8
3 changed files with 11 additions and 0 deletions
+6
View File
@@ -116,6 +116,12 @@ Item {
fadeWindowLoader.item.cancelFade();
}
}
function onDismissFadeToLock() {
if (fadeWindowLoader.item) {
fadeWindowLoader.item.dismiss();
}
}
}
}
}
+4
View File
@@ -60,6 +60,10 @@ Scope {
function lock() {
if (SettingsData.customPowerActionLock?.length > 0) {
Quickshell.execDetached(["sh", "-c", SettingsData.customPowerActionLock]);
// The custom locker manages its own surface; DMS never engages
// WlSessionLock here, so isShellLocked stays false and the fade
// overlay would never be dismissed. Hand off by dismissing it now.
IdleService.dismissFadeToLock();
return;
}
if (shouldLock || pendingLock)
+1
View File
@@ -53,6 +53,7 @@ Singleton {
signal lockRequested
signal fadeToLockRequested
signal cancelFadeToLock
signal dismissFadeToLock
signal fadeToDpmsRequested
signal cancelFadeToDpms
signal requestMonitorOff