This is intended as a replacement of sway’s idle management daemon. I use it as a tool to understand rust message passing and state management. It aims to have the following goals:
I am now using it as a replacement for any ac and battery power daemon, since I can run tasks with it.
Until packaging is added you can install sleepwatcher using cargo.
cargo install --git https://github.com/fishman/sleepwatcher-rs
sleepwatcher-rs uses env_logger
. You can enable logging by setting the RUST_LOG
environment variable:
RUST_LOG=debug sleepwatcher-rs
The default config is written to ~/.config/sleepwatcher-rs/idle_config.lua
on startup if the folder and file does not exist yet.
Lua is configured to be sandboxed, so no library functions can be used and only functions exposed inside the Rust can be used.
Important distinction between Helpers:run
and Helpers:run_once
. run_once
will check if a process of that name is already running and won’t spawn a new one in that case. This may be useful, when a screen locker can create race conditions if spawned twice.
Originally I wanted to reload the config whenever the AC adaptor is plugged in and out, but due to the timeout issue described below, you can check for the on_battery
state in functions.
Helpers:log("Loading idle_config.lua")
function LockScreen()
Helpers:log("Locking Screen")
IdleNotifier:run_once("swaylock -f")
end
function ScreenLockBattery(event)
if event == "idled" and Helpers:on_battery() then
LockScreen()
end
end
DbusHandler:PrepareSleep("LockScreen")
DbusHandler:LockHandler("LockHandler")
DbusHandler:UnlockHandler("UnlockHandler")
IdleNotifier:get_notification(300, "ScreenLockBattery")
get_notification
creates a Wayland idle timeout handler. It uses the ext-idle-notify-v1
protocol. It is not (yet) possible to create callback functions, so the function calls are made by specifying the name of the function.
PrepareSleep
, LockScreen
, UnlockScreen
, are dbus signals from the org.freedesktop.logind.manager
and org.freedesktop.logind.session
.
~/.config/sleepwatcher-rs/idle_config.lua
is changed. However, due to an unknown reason the first trigger after reload still follows the old timeout and the next trigger is therefore equal to the rest of the previous timeout+the new timeout setting.