Re: [hackers] [slock] Fix my previous commit and some light refactoring

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Thu, 1 Sep 2016 17:20:02 +0200

> I don't think a config.h variable is the best option. When starting
> slock from the terminal the problem does not occur, so you don't want
> a timeout in this case.
I don't really understand what you mean by that. Why wouldn't you want
a timeout then? Even when started from a terminal, the mouse can still
be grabbed for example.
What I mean is if it makes sense to have a timeout in one case, it's
valable for all other cases too.
Also that's a (maximum) timeout, not a strict delay. So when nothing
gets in the way of grabbing input, slock is automatically started
anyway without any waiting.

> For key bindings it's easy to just pass a
> command line flag. Therefore I favor a shell wrapper or the direct
> command line flag, while I think the direct flag approach is best,
> since it's job (waiting) can be done from C as easily as it would be
> in a shell wrapper, but it avoid one extra layer of complexity.
I used there the more or less arbitrary value of 600ms because the
default key auto-repeat delay of Xorg is 660ms.
The pro then for a command line option would be to be able to specify a
different timeout for each usage of slock (are there different ones?).

Making a behaviour with timeout and one without would add unuseful
(imho) complexity to slock code.
So I'd be to stick to timeout or no timeout at all, but not both.

Are there any other opinions beside those?
Received on Thu Sep 01 2016 - 17:20:02 CEST