hypridle icon indicating copy to clipboard operation
hypridle copied to clipboard

[Question] Using with hyprlock or swaylock, different timeout when hyprlock or swaylock is activated

Open omnigenous opened this issue 1 year ago • 5 comments

Is it possible with hypridle to have multiple conditional timeouts? I want to have one timeout for when hyprlock or swaylock not running. And other for when hyprlock or swaylock is running.

Example:

  1. hyprlock is not running/active, timeout = 600 seconds
  2. hyprlock is running/active, timeout = 60 seconds

Related: https://github.com/swaywm/swayidle/issues/159

omnigenous avatar Feb 20 '24 20:02 omnigenous

Can't you do just pgrep hyprlock && command?

asiantuntija avatar Feb 20 '24 22:02 asiantuntija

I think this can be closed? @omnigenous

alba4k avatar Feb 25 '24 19:02 alba4k

Can't you do just pgrep hyprlock && command?

The problem with this is that, lets say 60sec is for screen turn off if hyprlock active, and 100 sec is for screen lock. Now hypridle runs a single timer and executes timeout_action . Because 60sec idle timeout comes first, it executed its timeout_action - which will won't turn off the screen. Now idle timeout reaches 100sec and it will lock the screen. And now there are no listener, idle timer keeps on running but it won't reset to 0 unless mouse or key press is done. So 60sec timeout_action won't be executed again untlit hypridle resets.

KAGEYAM4 avatar Mar 12 '24 06:03 KAGEYAM4

Can't you do just pgrep hyprlock && command?

The problem with this is that, lets say 60sec is for screen turn off if hyprlock active, and 100 sec is for screen lock. Now hypridle runs a single timer and executes timeout_action . Because 60sec idle timeout comes first, it executed its timeout_action - which will won't turn off the screen. Now idle timeout reaches 100sec and it will lock the screen. And now there are no listener, idle timer keeps on running but it won't reset to 0 unless mouse or key press is done. So 60sec timeout_action won't be executed again untlit hypridle resets.

Why not make another listener then for turning off the screen at 160 seconds if one minute is the desired time after lock is invoked? I'm not against adding this feature, but I feel it's pretty simple to implement with a single command, and to change for whatever check you need to do. Other way around, lets say a function that checks for hyprlock is included in hypridle, if somebody wants to use swaylock then should that be added also, where does the checking end?

Maybe just documentation needs enhancing, so users know how to create these basic routines.

asiantuntija avatar Mar 12 '24 08:03 asiantuntija

Why not make another listener then for turning off the screen at 160 seconds if one minute is the desired time after lock is invoked? I'm not against adding this feature, but I feel it's pretty simple to implement with a single command, and to change for whatever check you need to do.

wow, didn't thought that, nice idea.

Other way around, lets say a function that checks for hyprlock is included in hypridle, if somebody wants to use swaylock then should that be added also, where does the checking end?

Yes this is totally not a good idea, i created a issue on hyplock so that screen_turn_off can be addressed by hyplock only.

Maybe just documentation needs enhancing, so users know how to create these basic routines.

Yes. i didn't knew that i had to use lock_cmd = pgrep hyprlock || hyprlock if not used then multiple instances of hyprlock will be started everytime timer-resets.

KAGEYAM4 avatar Mar 12 '24 08:03 KAGEYAM4

Solved, thank you :heart:

listener {
  timeout = 600
  on-timeout = pgrep hyprlockORswaylock || hyprlockORswaylock
}
listener {
  timeout = 660
  on-timeout = pgrep hyprlockORswaylock && command1
  on-resume = command2
}
# If no longer idle but still haven't unlocked
listener {
  timeout = 60
  on-timeout = pgrep hyprlockORswaylock && command1
  on-resume = command2
}

omnigenous avatar May 05 '24 23:05 omnigenous