Simon Tatham13h ago

Another week, another tiny utility.

I was in a Zoom call last week with very poor video quality, which we figured out was because I was also running a long compile which wasn't leaving Zoom enough CPU to work with. So I paused the compile with ^Z and things improved.

Three hours after the call, I found the compile job, still suspended, in a window hidden behind something else. Oops. If only I'd been able to arrange to _automatically_ resume the job when the Zoom call terminated, instead of relying on my own memory!

I already have a tool 'after' which waits for a specified Unix process to terminate. But Zoom stays running even when not on a call, and there's no reason to suppose it puts the call in an easy-to-identify subprocess.

But it does put it in a separate _window_. So I wrote a tool 'xafter', which waits for a specified X window to close. Completely trivial – X11 makes it easy to ask for StructureNotify events on a window whether it's your own or not. Now if I suspend a job that's interfering with my meeting, I can immediately type 'xafter;fg' and select the meeting window, and then it'll restart automatically.

I have no idea if it would be easy to write analogues of this for Wayland, or Windows, or Mac.

Show threadDaniel Carosone

@simontatham cool..

There's a similar thing under wayland used to suppress screen locking when apps are active that don't require the normal mouse and kbd interaction, like media players and conference calls.

Having jobs that only run when one of these inhibitors isn't held seems useful!

9:27amWeb
Show threadSimon Tatham12h ago
@uep and on the flip side, when an application fails to suppress the screen lock, I've been known to work around the problem by making a very cheap video file (small plain black rectangle at 1fps) and run a media player on it, which is easier than figuring out the proper lock-suppression API :-)
Show threadDaniel Carosone12h ago
@simontatham "the"? singular? LOL
Show threadSimon Tatham12h ago
@uep indeed, I've long suspected that part of the _reason_ applications sometimes fail to suppress my screen lock is that there's more than one API and they used the other one!
Show threadsmolwaffle9h ago
@simontatham
Indeed, and there's a problem with Firefox where it stops when it hits the first one that appears to be supported, even if there isn't anyone actually listening for the event. xdg portals create a lot of these problems today; in the past it was various screensavers and xset.
@uep