lid behavior watcher to lock session #115
Reference in New Issue
Block a user
Delete Branch "lid-switch-behavior"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #102
Use case
Laptop users often want a quick an intuitive way to lock their session by closing the lid. This PR includes logic to have session lock on lid close before suspend (or hibernate) kicks in. Works on systemd and elogind.
Summary
lidWatchdefaults totrueif a laptop battery is detected.falseif none are detected.Lockscreento configure if user wants it toggled.Optional additions
Known bug/caveat
lidWatchdisabled can still cause a short lock-like stall on lid open. No lock screen appears. Likely separate lock-session warm-up or suspend-path behavior.Currently broken. Do not merge!
@@ -0,0 +9,4 @@Connections {function onLidClosing(): void {root.lock.lock.locked = true;You need to create a signal in the root
Scopeand call it here rather than setting the locked value directly.Is what I suggest, ties in nicely with a similar signal related to locking.
@@ -0,0 +38,4 @@return m_available;}void LidWatcher::onPrepareForSleep(bool goingDown) {Doesn't this trigger only when the system is about to suspend/hibernate? There should be a way to query the lid state directly.
Correct. And in retrospect, not every distro has defaults where the system suspends when laptop is on AC. The idea was that it should only trigger when the system suspends or hibernates to cover it more broadly for desktops (if wished). Could be a separate plugin or addition to current implementation if that is a wish separate from laptop lid behavior.
@@ -329,0 +331,4 @@category: "lockscreen",categoryName: "Lockscreen",section: "Lockscreen",keywords: ["lid", "lcck", "watch", "session", "laptop"],Typo probably.
"lcck"should be"lock"I added clang rules for formatting and lint. I think this can be a decently good addition. Since you write C++ the most, I'll leave it up to you if you either want some rules changed, removed, or if you do not want these in the project at all.
I also found a fix of some sorts to the
Unknown argument: '-mno-direct-extern-access'warning you get including the header file. It does require changing the cmake file and a localcmake -B build. I did not commit this yet as I want your input if this hack is a fine addition.Edit: I was not careful enough, the hack is in the files changed. We can always undo.
The only thing that sticks out to me immediately is the line I commented on, other than that it looks fine to me.
Since I don't know what
-mno-direct-extern-accessmeans, are you sure using in-place substitution like this doesn't change the behavior and only makes the error disappear?@@ -0,0 +32,4 @@LidState m_state = Opened;void extracted();extracted()is declared but never implemented in the.cppfile.Resolved many issues by using Caelestia's implementation instead. With great assistance from @zach, got it to work.