shutdown_menu: should suspend also lock?

[Enrico Maria De Angelis]

This is not exactly an issue, but rather a question, because I am not sure what I expect is what everybody would expect.

Let's say I need a break and I want to go running for one hour or so, but I don't want to lose my session (windows and programs opened, and the likes). This rules out

• Cancel,

• Halt,

• Logout,

• Reboot,

• Shutdown,

leaving

• Lock, which successfully locks the screen, so that the password is required, but leaves everything powered on, wasting energy,

• Suspend, which powers almost everything off, but does not lock, so the password is not required when awaking it, which is potentially risky,

• Hibernate, which... well, it does not work for me, but given how it's defined (see below), I think it does not lock, just like Suspend doesn't.

From the shutdown_menu:

  [Lock]="${LOCKSCRIPT:-i3lock --color=${BG_COLOR#"#"}}"
  [Suspend]="systemctl suspend"
  [Hibernate]="systemctl hibernate"

[skidnik]

Combining system suspend with screen locking is not a job of power buttons. Most DEs handle this in their own way and have relevant settings. LightDM's light-locker daemon can do this automatically. Other DM's may also have a native locker mechanism, refer to their documentation.

In i3 xss-lock can start any standalone session locker for you.

[Enrico Maria De Angelis]

In this case, would it make sense for (some of) the entries of menu to be injected properties (with defaults), so that the user can customize them from the config file?

[skidnik]

Injected properties can be made for each button akin to LOCKSCRIPT one, current values as defaults with the possibility of defining alternative commands for buttons. This blocklet in its current state is compatible only with systemd/linux.

If you feel adventurous enough, make the changes and push them back according to contributing rules.