zach/z-bar-qt
1
1
Fork 0
Code Issues 22 Pull Requests 1 Actions Packages Projects 1 Releases Wiki Activity

Laptop lid behavior suspend/hibernate -> Locks screen #102

New Issue
Closed
opened 2026-05-26 12:13:48 +02:00 by AramJonghu · 4 comments
AramJonghu commented 2026-05-26 12:13:48 +02:00
Collaborator
Copy Link
Copy Source

With the current implementation, the only way the lock screen appears:

  • Manual input
  • Idle timers

There is no option to have it check for coming out of suspend/hibernate in general. Is this possible?

A C++ plugin can handle lid behavior. Then qml can pick this up.

  • Create plugin to listen to logind/elogind for lid behavior (closing or not).
  • Integrate into QML settings.
  • Add a settingswindow toggle to switch on or off lidwatch.
  • Have the default detect laptop battery or no battery to determine default behavior.
  • Test lidswitch enabled and disabled.
    • Must lock session before suspend occurs.
    • lidswitch disabled does not inhibit lock.
With the current implementation, the only way the lock screen appears: - Manual input - Idle timers There is no option to have it check for coming out of suspend/hibernate in general. Is this possible? A C++ plugin can handle lid behavior. Then qml can pick this up. - [x] Create plugin to listen to logind/elogind for lid behavior (closing or not). - [x] Integrate into QML settings. - [x] Add a settingswindow toggle to switch on or off lidwatch. - [x] Have the default detect laptop battery or no battery to determine default behavior. - [x] Test lidswitch enabled and disabled. - Must lock session before suspend occurs. - lidswitch disabled does not inhibit lock.
zach was assigned by AramJonghu 2026-05-26 12:13:48 +02:00
AramJonghu added this to the Zshell board project 2026-05-26 12:13:48 +02:00
AramJonghu added the bugquestion labels 2026-05-26 12:14:05 +02:00
zach commented 2026-05-26 13:40:11 +02:00
Owner
Copy Link
Copy Source

I honestly don't know if that's possible directly from QML. If you can find a way then I'll gladly implement it, but the reason we have the lock() IPC call is so that you can lock it whenever you want it to lock, meaning you can set up whatever your equivalent of a systemd service with a trigger is to call the lock method.

I honestly don't know if that's possible directly from QML. If you can find a way then I'll gladly implement it, but the reason we have the `lock()` IPC call is so that you can lock it whenever you want it to lock, meaning you can set up whatever your equivalent of a systemd service with a trigger is to call the lock method.
AramJonghu commented 2026-05-26 19:41:06 +02:00
Author
Collaborator
Copy Link
Copy Source

I did some digging. I have two main options.

  • Write a script on my system(s) to call lock when out of suspend/hibernate.
  • Write it myself into this project. This could be used for systemd, elogind (so no systemd), or anything else.

I like to write it myself if that is ok. It was suggested to write cpp, but my preference would be zig. I'd write a package like zshell-elogind-lock/ or similar. Would you be okay with zig in the project? In the end, it would be a binary that we'd end up using. What is your preference?

Edit: Python is another option indeed in our current codebase.

I did some digging. I have two main options. - Write a script on my system(s) to call lock when out of suspend/hibernate. - Write it myself into this project. This could be used for systemd, elogind (so no systemd), or anything else. I like to write it myself if that is ok. It was suggested to write `cpp`, but my preference would be `zig`. I'd write a package like `zshell-elogind-lock/` or similar. Would you be okay with zig in the project? In the end, it would be a binary that we'd end up using. What is your preference? Edit: Python is another option indeed in our current codebase.
AramJonghu moved this to Review in Zshell board on 2026-06-01 20:51:53 +02:00
AramJonghu commented 2026-06-01 21:00:31 +02:00
Author
Collaborator
Copy Link
Copy Source

In the end, it will be a cpp plugin which can be enabled or disabled. I will update the original issue to show criteria.

In the end, it will be a `cpp` plugin which can be enabled or disabled. I will update the original issue to show criteria.
AramJonghu added reference lid-switch-behavior 2026-06-01 21:01:01 +02:00
AramJonghu changed reference from lid-switch-behavior to lid-switch-behavior 2026-06-01 21:08:35 +02:00
zach was unassigned by AramJonghu 2026-06-01 21:08:38 +02:00
AramJonghu self-assigned this 2026-06-01 21:08:39 +02:00
AramJonghu commented 2026-06-02 00:38:30 +02:00
Author
Collaborator
Copy Link
Copy Source

@zach if you can assist.

Current issue I am facing is:

  WARN scene: @Daemons/LidService.qml[12:-1]: TypeError: Cannot read property 'lock' of undefined
  WARN scene: @Daemons/LidService.qml[12:-1]: TypeError: Cannot read property 'lock' of undefined
@zach if you can assist. Current issue I am facing is: ``` WARN scene: @Daemons/LidService.qml[12:-1]: TypeError: Cannot read property 'lock' of undefined WARN scene: @Daemons/LidService.qml[12:-1]: TypeError: Cannot read property 'lock' of undefined ```
zach closed this issue 2026-06-03 18:02:21 +02:00
AramJonghu moved this to Done in Zshell board on 2026-06-03 18:02:56 +02:00
Sign in to join this conversation.
lid-switch-behavior
Branches Tags
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label bug question
Milestone
No items
No Milestone
Projects
Clear projects
No project Zshell board
Assignees
Clear assignees
AramJonghu Inorishio zach
No Assignees AramJonghu
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: zach/z-bar-qt#102
Delete Branch "%!s()"

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?