On 28/09/21 11:33 pm, Dan Ritter wrote:
Richard Hector wrote:
On 27/09/21 11:39 pm, Dan Ritter wrote:
>
> One option is to run a mute and stop-playing command immediately
> on screensaver interaction.
>
> For XFCE4, that's as easy as adding a panel object which runs an
> application, pointing that at a script, and adding an
> appropriate icon. Install xmacro.
>
> ~/bin/quiet-and-dark
>
> #!/bin/sh
> #not actually tested
> echo 'KeyStrPress XF86AudioPlay KeyStrRelease XF86AudioPlay' | xmacroplay :0
> echo 'KeyStrPress XF86AudioMute KeyStrRelease XF86AudioMute' | xmacroplay :0
> xscreensaver -command activate
>
>
> You can also assign it to run as a keyboard shortcut.
Thanks Dan,
If I understand correctly, you're suggesting to create a clickable button
which will mute the audio, and then creating a macro to do that from within
a script, which I then need to run manually?
That sounds inverted. The button executes a script when you
click it; the script mutes and pauses audio, then activates the
screensaver.
There might be a way to invoke the mute-and-pause from the
screensaver when it activates by itself, but I don't know that
one and a few minutes searching didn't reveal it.
I'd like this to still happen if the screen locks due to inactivity. I
haven't found yet what triggers that, or where to configure the timeout.
That's in Settings, Screensaver. Try right clicking on an empty
area of desktop.
Secondly, will it re-enable audio when the screen is unlocked?
This won't, but the same invocations without the final
screensaver activation will un-mute and start playing whatever
is listening to XF86 media keys.
Thanks Dan, I think I understand some of that.
However, I'm reluctant to embark on one-off efforts, partly because I
don't understand enough of the underlying structure, and partly because
it only solves it for me (if I understood more, maybe I could contribute
back, but I don't).
As I say, I consider this to be a security flaw - people can hear
something of what my computer's doing when I'm not there and it's
supposedly locked.
Do others agree with that?
Also, I don't know how much of the screen locking function is shared
between the many tools that are available for this purpose. Ideally,
this problem (if it's a problem) should be fixed in all such tools.
Does it sound reasonable then to submit a bug report to light-locker,
with the suggestion that the maintainers contact the maintainers of
similar/related packages as they see fit?
Cheers,
Richard
