Feature-Request: Unlock-Hook

[SebTM]

This issue is a....

[ ] Bug
[X] Other kind of issue (Please describe in detail)

Topic

We currently implementing stopping/resuming notifications while locked and I wanted to ask if there are some better ways to check/hook into unlock. (betterlockscreen/betterlockscreen#219)

If not, would it be an option to implement something like unlock-Hook in the future?

[Raymo111]

Can you just have a check for the PID of the i3lock process? Since there should only be the instance that betterlockscreen launches and no other i3lock processes right? So the hook can just be when i3lock exits? (Which it does when the screen is unlocked.)

[Rio6]

Another alternative is to start i3lock with --nofork option and run command after it finishes.

[souravdas142]

Another alternative is to start i3lock with --nofork option and run command after it finishes.

yeah @Rio6, This is more logical I think instead of #225 (comment) ? I already implemented #225 (comment) see betterlockscreen/betterlockscreen@64eea99 (something like busy wait) wouldn't it consumes lot of cpu resources @Raymo111 ? difference between with or without --nofork ?

[bew]

Busy wait will use cpu for nothing, it's not really efficient..

Instead if you want to start the locker, and wait for it to end before doing something else you can use --nofork:

# do before lock hook stuff here

i3lock ..... --nofork
# the script will block until the screen is unlocked and i3lock returns

# do unlock hook stuff here

Another way is to use the shell to put i3lock in the background, save the pid, do other things and finally wait efficiently for i3lock to exit:

# do before lock hook stuff here

i3lock ..... --nofork &
# Using `--nofork` and `&` ensures the PID we get with `$!` is the process of the locker, not of a bootstrap process (like the default)
SAVED_PID=$!

# now i3lock is still running in the background, we can do other things...

# to wait for i3lock to exit efficiently, use:
wait "$SAVED_PID"

# do unlock hook stuff here

[Raymo111]

@souravdas142 fork means i3lock-color will run in the background, and anything in the script after the i3lock command will be run immediately after the lockscreen starts. No fork means any command in the script after i3lock will run after i3lock exits, once the screen is unlocked.

[souravdas142]

Thank you @Raymo111 now there is no confusion.

[souravdas142]

Thank you @bew Tested all from #225 (comment) , both have the same effect but later version enables you to do other things while i3lock-color runs in background. Now which version is better in terms of cpu consumptions or efficency? @SebTM @bew

[SebTM]

I don't see a real need for running forking per default in Betterlockscreen, so if no one has concerns I would go with running Betterlockscreen non-forking per default (we would need to adjust systemd-service again) and rename postLock to postUnlock.

The only thing which came to my mind was: Do we need a postLock function somehow like executing something after i3lock-color launched? And from the current cases we have/had I don't see the need.

So thanks @Raymo111 @bew @souravdas142 for the Feedback and Help!