On Wed, 28 Sep 2016 21:17:23 +0200
Markus Teich <markus.teich_AT_stusta.mhn.de> wrote:
Hey Markus,
> I don't think it is that obvious. Have a look at the discussion
> starting from the slock-1.3 announcement on February 12th this year
> again. Since the example does not work any more, changing it to
> `slock sudo s2ram` and adding a note about the needed line in the
> sudo config so s2ram can be run without a password would be better.
the problem doesn't end there. Also, s2ram is Linux specific and in 99%
of the cases you run unprivileged after-lock commands.
To be honest, I expect any half-decent user how to set up doas or sudo.
> The other block looks good and is more simple and flexible than
> changing the xkb config ourselves from slock.c.
Yes, the problem really is that if we did the xkb changes within
slock.c, we somehow would have to cache the option string. If for any
reason it is changed while slock is running (automation, whatever),
and we uncache it, this can lead to strange behaviour.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Wed Sep 28 2016 - 21:25:13 CEST