I've attached a patch which implements the previously described change in behavior. IMHO it is perfectly cromulent behavior for -locknow to override -disable and I'm reluctant to submit a more complex patch unless the change in behavior actually breaks something for someone.
If this change in behavior does break some user expectation, I can write an alternative patch up that adds a option that adds some sort of -enableAndLockNow option. But until such a report comes in, I think its safe to assume that the current behavior is actually surprising and undesirable. -- Jon Doge Wrangler X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
Description: Fix -locknow to imply -enable The -locknow option should do just that regardless of whether or not xautolock is enabled or disabled. Author: Jon DeVree <n...@vault24.org> Bug-Debian: https://bugs.debian.org/720362 --- xautolock-2.2.orig/src/message.c +++ xautolock-2.2/src/message.c @@ -88,7 +88,12 @@ exitByMessage (Display* d, Window root) static void lockNowByMessage (Display* d, Window root) { - if (!secure && !disabled) lockNow = True; + if (!secure) + { + resetTriggers (); + disabled = False; + lockNow = True; + } } static void
