Screenlock inhibition while recording is paused wastes power and is a security problem

[nekohayo]

I was wondering why my computer was not only not suspending, but also not locking its screen... and I've come to suspect it is because I have Reco currently running with a paused recording. Issue #79's #88 seems to confirm my hunch.

I consider this a power consumption problem and a security problem, much like https://gitlab.com/zehkira/monophony/-/issues/164 (that ticket also has some of my advice for correct implementation). An audio-only app should not block screen lock, especially when the user may not be sitting in front of the screen.

Here is what I would suggest changing:

• Ideally: only inhibit suspend, never screen lock.
  There may be reasons to leave a recording going in a meeting while letting the screen lock if the user has not been actively using the session: maybe the user would want to ensure only they can stop the recording (or to be inconspicuous), and also keeping the screen turned on, particularly on laptops and mobile devices, is a huge battery drain.

  • If you don't want to do that "all the time" (or to make it configurable), then: it should definitely not inhibit screen lock when the recording is "paused", because the user may have walked away, and then that means anyone can physically access their unlocked workstation.

• While recording is "paused", it should also not inhibit suspend, because it's still a big waste of electricity or battery power. I might have started recording a meeting with someone in the evening, then want to continue that meeting on the next morning… but in the meantime, the computer should be allowed to sleep.