Why depend on scrot if you already require imagemagick for convert?

[espoelstra]

Since you already have imagemagick you should have both convert and import. You can easily use import in place of scrot with a line like import -window root $file1 < /dev/null. The < /dev/null bit is there because import can also be used to click and drag to collect only a portion of the screen, but with -window root we are getting the entire current desktop.

I've been using this myself since I didn't want to mess with scrot and it seems possibly slightly faster, but probably a false impression.

[ashinkarov]

I don't think there is a particular reason why scrot is the default. Your argument is that by using import we can get rid of scrot dependency. In principle, I wouldn't have anything against it. However, a short test indicated that import is tow times solwer than `scrot'. Here is what I do:

/tmp|=> time import -delay 0 -window root x.png </dev/null
import -delay 0 -window root x.png < /dev/null  1.22s user 0.07s system 99% cpu 1.295 total
/tmp|=> file x.png
x.png: PNG image data, 5280 x 2560, 8-bit/color RGB, non-interlaced
/tmp|=> ll x.png
-rw-r--r-- 1 tema tema 889K Jun 16 23:27 x.png
/tmp|=> # The same for scrot
/tmp|=> time scrot -z -d0 "x.png"
scrot -z -d0 "x.png"  0.53s user 0.02s system 96% cpu 0.573 total
/tmp|=> file x.png
x.png: PNG image data, 5280 x 2560, 8-bit/color RGB, non-interlaced
/tmp|=> ll x.png
-rw-r--r-- 1 tema tema 1.1M Jun 16 23:28 x.png

I can see that the file generated by import is smaller, but I don't really like that there is such a noticeable delay. Maybe one could pass some arguments to import to speed things up?

As for dropping the dependency, I am happy to conditionalise the call to scrot falling back to import in case it is not found on the system. However, as long as we can make import run faster, I would still use scrot as default.

Are you interested in creating a patch for this?

[espoelstra]

I'll see if I can find time to take a look soon. I basically made a one liner to do my locking, but I definitely like the idea of the padlock overlay to make it a little more obvious that the system is secure.

I have also wondered about whether it would be possible to periodically "refresh" the blurred screenshot in case you were waiting for a process to finish but were working on another system and didn't want anyone shoulder surfing information.

[ashinkarov]

I don't see a trivial solution for the refreshing bit. You'd have to either smarten-up i3lock so that it would reload the file; or you'd have to relaunch i3lock on timer, making sure that multiple instances of i3lock do not conflict, at least one i3lock instance is running and that user can exit the screensaver :)

If you have a good idea or a working prototype, we can discuss it further.