Coordinating changes to shell's screenshot service?

Hi all! A few months ago I put together some experimental patches to the shell, gsd, and the gnome-screenshot tool to move up the timing of the “flash” visual effect and “shutter click” sound effect to before PNG compression, which greatly improves perception of reaction time of screenshots with the PrintScreen key on slower machines with high resolution screens.

I’m hoping to get this back in motion during the new development cycle, but want to first double-check if there’s anything else that might be using the Shell’s screenshot service that might need to be updated, and how important it is to maintain backwards/forwards compatibility with the flash or sound effect behavior.

Ideally, I think the service should manage the ‘flash’ and ‘click’ effects, but these need to be optional in case contacted by an old desktop client that does its own sound effect… I think. :slight_smile: Or, I can have the service simply add a signal for when the capture occurs, and let the clients manage their sound effects based on that… but that could lead to getting out of sync with mismatched clients (new shell shows a flash at beginning of compression, then old gnome-screenshot runs a click at the end, or vice versa). I’m worried that mismatched clients are more likely in the Flatpak world where people can easily test new applications on an old shell/host platform…

Anyone have recommendations or can point me in a good direction? Thanks!

2 Likes

Hey, thanks for picking this up!

xdk-desktop-portal-gtk, but it doesn’t do a sound effect as far as I can see.

I don’t think this is a big concern. Applications should use the screenshot portal, not the underlying (private-ish) Shell D-Bus API. This is especially important for flatpak apps, because allowing an app to talk directly to the Shell’s D-Bus APIs undermines any sandboxing that is in place.

And if anything other than gnome-settings-daemon, gnome-screenshot and the portal implementation ends up using the Shell D-Bus interface, a duplicate or missing shutter sound isn’t the end of the world. At least IMHO it doesn’t justify jumping through hoops to avoid those glitches for everyone at all costs.

Putting aside that sandboxed apps really really really shouldn’t talk directly to Shell D-Bus services, the most likely combination is newer app with older desktop, which means a missing shutter sound. That’s less obviously broken than the other glitch (duplicate sounds), so I suspect most users wouldn’t even notice it :man_shrugging:

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.