Screenshot portal without prompt

[lionirdeadman]

This may seem dangerous but for screenshot applications, this sounds necessary from a design POV. Having a screenshot application which asks twice to screenshot would be quite awkward, I think.

Related : https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970 , flameshot-org/flameshot#1910

[smcv]

Is your request something like this?

• Invent some special metadata that can be set on a Flatpak (or Snap?) app, with the semantics "this app can take screenshots without prompting". Flatpak (and Snap?) would not do anything differently in setting up sandboxes based on this metadata, it's just a marker.
• Make the screenshot portal look for that metadata in /.flatpak-info. If it's present, just take the screenshot without prompting, with parameters (window/whole screen/etc.) controlled by the request.
• Maybe the portal backend is still responsible for visual/audio feedback (screen flash/shutter sound) to make sure the user is aware that a screenshot was taken?
• Ideally, app stores like Flathub limit access to that metadata (more review required), in the same way they ideally would for other "dangerous" permissions like host filesystem access.

Or a possible alternative would be to do something a bit like #638:

• Have a flag that the screenshot app can set, to say "I'm always going to need this permission"
• The first time that flag is used, have a prompt with some sort of "remember this" option
• Make a note in the permission store that this app is OK to take screenshots any time, or give it a token that can be looked up in the permission store later, or similar

Or a mixture of the two: ignore or reject the flag from the second approach if it's set by an app that doesn't have the permission metadata from the first?

[lionirdeadman]

I think it should be strictly easy to control so it shouldn't be metadata (and require something like Flatseal to change).

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

[borgmanJeremy]

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

This is my proposal as well, similar to permissions on a mobile OS.

(I am the maintainer for the screenshot program Flameshot)

[DamirPorobic]

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

Agree with this one. The user experience with pop up dialogs that require additional clicks every time you take a screenshot is just not a way to go.

I'm the developer and maintainer of ksnip.

[mcatanzaro]

I think it should be a one-time prompt like there is for the background or camera permission. I suppose it wouldn't be a bad idea to make the permanency of it optional as to make the use case for it more flexible though.

Giving the user the option to grant the application permission to take future screenshots/screencasts without further user permission would be OK. We just don't want the application to be able to give itself this permission, or to be able to force the user to grant this permission in order to use it just once.

So let's forget about additional metadata. I would retitle this issue from "Screenshot portal without prompt" to "Screenshot portal should have toggle for user to disable future prompts for this application."

[DamirPorobic]

As part of such change it would be useful to pass the type of screenshot that should be taken. The prompt that opens up is not just a permission thing but also a selection of type of screenshot (and if the cursor should be included eventually).
If the user for example first asks for Active Window screenshot and confirms that he don't want to be asked again, what happens when the user requests another screenshot and expects to get a fullscreen screenshot now. Currently there is just an option to ask for scrrenshot but not what kind of screenshot.

[mcatanzaro]

OK, makes sense. So: add API for application to choose the type of screenshot that should be taken, only show the option to permanently grant permission to take screenshots if the new API is used.

That wouldn't apply the same to screencasts, but those are a separate portal.

[DamirPorobic]

Yeah, I think just a dialog that asks for that permissions with an option to make it permanent would in that case be the best, without any other selection option. Bonus points for additional parameter in the API call like "Include cursor" and "Include window decoration".

That wouldn't apply the same to screencasts, but those are a separate portal.

Yes, I think it was a different API but I can imagine that they have similar issues if they haven't been fixed already.

[Midnex]

I hope you only have to give permission one time, and then from there it can do it every time. This would be more secure than the old method, but less annoying then the current.

[kurobeats]

Can I express how powerless this issue makes me feel in relation to Gnome development. The tone from the Gnome folks here: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970 indicates to me this issue will not be resolved/is not considered an issue. Creating a Gnome related bug report is akin to shouting into the void, isn't it?