Don't start timers that are already running
Closed this issue · 10 comments
If timer #1 starts a lockscreen, and the user moves his mouse while still in the lockscreen, timer #1 shouldn't re-trigger - it's already running. Instead it should move on to trigger timer #2 after continued idle time.
See this comment by @Meister1593
I implemented your suggestion @Meister1593. I'd be happy if you could try out the version on the latest master. I added a test script called test-usecase.sh which runs a pretend lock-screen and counts up to when it would fake a suspend. You'll notice the fake lockscreen is restarted if you close it and are active, but otherwise it never starts it when it's already running
I implemented your suggestion @Meister1593. I'd be happy if you could try out the version on the latest master. I added a test script called
test-usecase.shwhich runs a pretend lock-screen and counts up to when it would fake a suspend. You'll notice the fake lockscreen is restarted if you close it and are active, but otherwise it never starts it when it's already running
i just ran my current locking script with current master, after second timer and activity, it waits for first timer and runs lock again, even if it's running currently
so like nothing changed for me, possible reasons?
The usecase script runs, then makes suspend box, i press ok and it restarts timer
i suppose it's how it works, but not for my lil script with 2 timers and lock screen somewhy
It seems that adding args to any continuous-working program within timer breaks proper behaviour and it resets whole sequence
I tested it like this:
xidlehook \
--timer 5 "kate /etc/pacman.conf" "" \
--timer 5 "echo suspend" ""
When i do like that, i wait for echo suspend, make some interaction, then wait for second timer to trigger
Instead, triggers first timer.
When i remove argument from first timer kate (it can be any program with continuous work), it starts working properly (only second timer triggers when program is opened)
Btw i added -git AUR package that builds git version of xidlehook
https://aur.archlinux.org/packages/xidlehook-git/
xidlehook \ --timer 5 "kate /etc/pacman.conf" "" \ --timer 5 "echo suspend" ""
Are you saying this will sometimes launch two kate instances at the same time for you? Because if you close kate it should pop up again (just like how if you unlock it should restart and lock again), but not if you don't close it
xidlehook \ --timer 5 "kate /etc/pacman.conf" "" \ --timer 5 "echo suspend" ""Are you saying this will sometimes launch two kate instances at the same time for you? Because if you close kate it should pop up again (just like how if you unlock it should restart and lock again), but not if you don't close it
It's launching kate instance again when i don't exit first kate. So, it ignores existence on first kate (which is working at the moment) and proceeds to launch it again anyway.
I know that kate actually attaches new tab inside other instance of kate, so i checked it again on zenity --calendar and on termite /test (just to test arguments failing)
I couldn't reproduce it on either of those double launch, but it happens on my i3-lock, something is wrong with detection when arguments passed.
I also noticed that instead of 5 seconds on second timer, it waits about 8 seconds to trigger second timer with these two commands above. It can vary from 4 seconds up to 10 seconds from what i could see, something is weird about timing there.
Is it possible that xidlehook can't detect forked process?
EDIT: Yes, it can't detect forked process. To test you can use this:
xidlehook \
--timer 5 "zenity --calendar &" "" \
--timer 5 "echo suspend" ""
This will launch second instance of calendar whenever first is launched or not (after second timer and user interaction)
Xidlehook might need to handle forked processes (killing child processes (forks) after xidlehook terminates is also i thing needed to be considered of) in order to properly work with various programs
xidlehook probably should not detect forked processes, since that's the user's escape hatch to get the previous behaviour. You can use i3lock -n to wait for i3 to start.
I'll reopen the issue and try to take a look at the timing bug
I think commit be3faea fixes the timing bug?
Yup, timing is much better now. Using i3lock -n is also fixed issue with forking processes.
I guess issue can be closed