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

2016-09-02 Thread Quentin Rameau
> 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!

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

2016-09-02 Thread Markus Teich
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

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

2016-09-01 Thread Quentin Rameau
> 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

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

2016-09-01 Thread FRIGN
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

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

2016-09-01 Thread Markus Teich
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

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

2016-09-01 Thread Quentin Rameau
> 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

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

2016-09-01 Thread Markus Teich
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

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

2016-09-01 Thread FRIGN
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