Closed mfontani closed 3 years ago
Thanks for your PR.
Given that i3lock is a security-sensitive program, I would rather not have it reload anything in lock state. Even small mistakes, like a 1-byte memory leak, can manifest themselves as a lock screen circumvention bug.
More features are often accepted in i3lock-color.
Hi,
I've been using these proposed two patches on top of i3lock for quite some time now, and I'm testing the waters about whether they could be merged upstream instead of sitting in a branch, with no other user than myself.
The point of those patches is to allow refreshing the image used for locking the screen upon receiving a signal (i.e.
USR1
).As to the use-case...
When one wants to use an amended screenshot of the current screen to lock their screen, they usually proceed as follows:
The step at "2." may take quite a bit of time, and while "2." performs its tasks the screen isn't yet locked. If "2." moreover fails, it's possible the screen is never effectively locked.
With these patches, my process is now:
In case the "3." step above takes an inordinate amount of time or fails, the screen is locked.