See how the Flameshot screenshot utility handles it; it requests access to screenshots, and from there becomes the screenshot handler. Though on GNOME, the printscrn key goes through the shell, and not the portal, so that needs some fixing somewhere.

I'm not sure what you mean. As far as I can tell, on Wayland Flameshot goes through the portal on DEs that are not wlroots-based.

https://github.com/flameshot-org/flameshot/blob/a447b3d672ef92acb98be996d58540e36db84e35/src/utils/screengrabber.cpp#L123-L130

On DEs that aren't wlroots-based, like GNOME, Flameshot requests access to screenshots, and it opens its UI when the screenshot is pressed - selection, editing, etc. I assume that's what you want.

I don't really understand what you mean by "request access to screenshots". My point is that screenshot tools that implement their own capture/edit workflow cannot rely on the backend-provided dialogue (calling with interactive: true), but the dialogue provides more features than calling the Screenshot method with interactive: false.

Hm, I remember flameshot being able to ask for access to screenshots, and it would show whenever a screenshot is taken.... I wonder what happened to that. Revoking the permissions and rerunning it doesn't have that result anymore. It's late here, and I probably can't debug this more - but I'll see what I can do tomorrow.

@yamplum: I think Flameshot makes the request to take a fullscreen screenshot and then displays it with its tools on top. in other words, with Flameshot, you select the screen area on a fullscreen screenshot.

@yamplum: I think Flameshot makes the request to take a fullscreen screenshot and then displays it with its tools on top. in other words, with Flameshot, you select the screen area on a fullscreen screenshot.

Yes, it does, for Flameshot is pretty fine, but isn't enough for many other screenshot tools that don't just take a full screenshot and work with that.
That is the point, non-interactive screenshot only allows taking full screenshots, and don't allow to: Show/Hiding the pointer, waiting a specified time before a screenshot, include window decorations, only of the active window and screenshot of a window even if it doesn't is on focus/minimized.
I think it is the reason most of the screenshot programs don't work on Wayland or the reason spectacle and gnome-screenshot are compositor-exclusive.

Related issues that prove the need to work on this or even in other things:

Spectacle: https://invent.kde.org/graphics/spectacle/-/issues/12#note_665053
Shutter: shutter-project/shutter#662 (comment)
ksnip: ksnip/ksnip#976
GNOME Screenshot: https://gitlab.gnome.org/GNOME/gnome-screenshot/-/issues/237

Those issues and other discussions related to the Wayland support in screenshotting tools; have discarded or neglected the usage of the portal, as the maintainers concluded that isn't good enough or isn't possible for the portal to give them the UX parity with their X11 current implementations.

Currently, the portal asks to let the app take (fullscreen) screenshots at any time. For this reason, I see no problem directly calling a specific method of the interactive mode (+ selection of a specific window), provided that on the UI side the relevant mode can be leaved. For example, Georges made https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/118. The Gnome Shell Screenshot UI can be leaved.

Now, it's up to the portal maintainers to tell their opinion on this.

I think Flameshot makes the request to take a fullscreen screenshot and then displays it with its tools on top. in other words, with Flameshot, you select the screen area on a fullscreen screenshot.

This is what Shutter does on X11. We didn't do it on wayland through portal, because some portal implementations (namely, gnome) insist on showing the interactive window to let user select what screenshot to take, and we cannot control which backend of the portal will respond to the DBus call. This makes the workflow very broken:

1. user clicks a button "do area selection with a delay",
2. user sees a window which offers many different options of how to do screenshot (and area selection may or may not be one of them)
3. does some screenshot
4. then shutter takes over again, and offers to select the area in the resulting image (hoping that it was in fact the full screen)
5. user confirms the selection
6. delay starts
7. after the delay user is presented with that interactive screenshot window again
8. after user is done with the screenshot, shutter would crop the image using the selected area from step 5

Even worse scenario happens if the portal backend implementation doesn't match the compositor running, in which case there's no feedback from the API, and we just need to wait for a timeout. Then what happens if it was gnome backend, and the user actually is taking time interacting with the gnome screenshot interactive window, triggering our timeout?

These issues make portal unusable other than as a fallback option.

because some portal implementations (namely, gnome) insist on showing the interactive window to let user select what screenshot to take

That's no longer the case since maybe version 2 of the portal, as you can select between being interactive or not. If not interactive, then the portal asks if user wants to give permission to the app to always take screenshots.

In my opinion, the thing that make more sense for this portal would be:

• Have all screenshot options as being directly callable. This presents UI with ability to leave the interface and to confirm screenshot.
• Two permissions: taking screenshots with confirmation (i.e. clicking on Capture) and without confirmation (and without the effect we have in gnome-shell, but this need discussion).

Would it be possible to expose some of those interactive options on the D-Bus interface to bring the methods up to parity?

I agree with the idea. Exposing directly the select area or select window (other options too) would be very helpful... they are already done, just need to expose them.

@KelvinNovais: See #1415