> Heyho Quentin,
Yo Markus,
> After some reconsidering, I merged the patch as you proposed it. The
> other three are merged as well. Thanks for the contribution.
Thanks!
Heyho Quentin,
Quentin Rameau wrote:
> 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
> 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
On Thu, 1 Sep 2016 15:05:09 +0200
Markus Teich wrote:
Hey Markus,
> 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. For key bindings it's easy to
Quentin Rameau wrote:
> My preference would have been to completely remove the waiting behaviour
> outside of slock and maybe provide a simple shell script wrapper like sleep 1;
> slock. Another solution (as discussed with FRIGN) would have been to force
> other applications to ungrab input
> Heyho Quentin,
Hi Markus,
> in the commit message you mentioned spawning slock from other GUI
> applications via keybindings as the case where it won't work. If this
> is the only case, I think it would be cleaner to add a command line
> switch where the user can specify a wait time and after
Quentin Rameau wrote:
> My last commit removing the input grabbing waiting loop was a mistake, I
> tested it on a specific setup which didn't raise any error while regular
> setups should do. So the second of the four next commits fixes that.
Heyho Quentin,
in the commit message you mentioned
On Thu, 1 Sep 2016 13:45:24 +0200
Quentin Rameau wrote:
Hey Quentin,
> My last commit removing the input grabbing waiting loop was a mistake,
> I tested it on a specific setup which didn't raise any error while
> regular setups should do.
> So the second of the four next