Requirements to access org.freedesktop.portal.Screenshot?

[dynobo]

Dear flatpak Team,

I'm developing a small screenshot utility called NormCap and was struggling to get it to work with the latest Gnome release from within a flatpak. After some investigation, it seems to me like a flatpak-app now needs to fulfill two requirements when requesting a screenshot, at least for the first time:

1. At the time of sending the request via DBUS, the app needs to have an (active?) window.
2. interactive needs to be True.

If one of the prerequisites is missing, the dialog asking to grant the app permission to access the screenshot feature will not appear → therefore the app doesn't get the required permissions → with the result that the app never receives a response, neither with the URI to the image, nor an error.

(Sidenote: After the requirements were met once, and the permissions got granted, I'm successfully able to receive the screenshot URI without any visible window and with interactive set to False.)

Now my questions/suggestions:

1. Is this intended behavior?
2. If yes, might it be a good idea to add these details to the documentation?
3. The requirement (1) of having an active window when requesting the screenshot for the very first time is quite cumbersome for apps like mine, that use the screenshot as prerequisite for creating the initial window. I currently try to solve this, by showing a placeholder window first, but this isn't good UX. Is there a technical reason for that requirement? If not, I'd propose to drop it. :-)

Thanks for your great work! 👍

[Mikenux]

See from flameshot-org/flameshot#3213 (comment)

@swick also opened #1093

[GeorgesStavracas]

It's unclear if what needs to happen is documenting the current behaviour, or changing the current behavior.

[dynobo]

It's unclear if what needs to happen is documenting the current behavior, or changing the current behavior.

Exactly.

For what it's worth: for applications like mine or flameshot, etc., it would be beneficial to the UX to not require an open active window.

Or at least to offer a way to query if the permission is set or not or return a "permission denied" error or something. Currently, I'm doing the DBus request and wait an arbitrary time (e.g. 15s) to see if I get a response or not, because I don't even receive an error in case of missing permissions. That means the user has to wait that time span (which has to be quite long, as screenshots on 3x 4K displays can take ~15s over portal), before I can present a "open active window" as workaround and do an interactive request again.

[swick]

There are a few cases with portals now where it might be good to have some way to let clients see the state of the permission and let the client open the system settings to let the user change a specific permission.

Obviously it's not clear if we want a feature like that in general. We tried hard so far to avoid this kind of explicit permission granting system and instead grant permissions implicitly. Probably something we need to discuss at a higher level first before coming back to this issue.