hyprwm / hypridle

Hyprland's idle daemon
BSD 3-Clause "New" or "Revised" License
373 stars 22 forks source link

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

Closed omnigenous closed 5 months ago

omnigenous commented 7 months ago

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

asiantuntija commented 7 months ago

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

alba4k commented 7 months ago

I think this can be closed? @omnigenous

KAGEYAM4 commented 6 months ago

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.

asiantuntija commented 6 months ago

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.

KAGEYAM4 commented 6 months ago

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.

omnigenous commented 5 months ago

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
}