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.

… I forgot to provide a link, didn't I? See, that's why I prefer to avoid relying on my own memory.

'xafter' is available from my miscellaneous utilities page (also including 'after' and lots of other unrelated things):
https://www.chiark.greenend.org.uk/~sgtatham/utils/

Simon Tatham's miscellaneous utilities collection

@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!

@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 :-)
@simontatham "the"? singular? LOL
@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!
@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
@simontatham nice, I need this
@webhat well reminded, I've now put a link in a followup post!
@webhat @simontatham talking about nice, `nice -n 19 COMMAND` runs your command in the lowest CPU priority, which could have helped in this situation.
@mdione
Sometimes! But there are three problems:
1. nice does not affect I/O
2. Programs running in containers require cgroups settings instead
3. Thermally limited devices such as laptops will still throttle the CPU speed even if the priority of the processes creating the heat is low
@webhat @simontatham
@smolwaffle @mdione @simontatham the processes would still be scheduled, it would just be interrupted more often. Many builds have multiple threads/jobs which are spawned, and with a lot of processes the CPU/scheduler might still throttle the Zoom call
@webhat @smolwaffle @simontatham I used tom compile software with `nice -n 19 make -j NUM_CPUS`, but that was a _long_ time ago. now I do an equivalent thing for map tiles, and it never seemed to interfere with the rest. Not sure I tried while zooming. Granted, part of it is IO bound (waiting for postgis to return data), but once it's deep enough (low data count per tile) it's all CPU bound. No complaints, on a 2018 laptop (32G, nvme disk).
@simontatham A thing I do is to add a `(J)` marker to my prompt if there are suspended jobs
@simontatham Which requires me to _look_ at that specific shell, but at least I'll see

@Lalufu right – in my case, when the entire terminal window was concealed behind something else, that still wouldn't have helped!

But it's true that in other situations I can carry on using a shell and forget that there's been a suspended background job in it for the last half hour.