Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring non-interactive screenshot options to parity with interactive ones #1065

Open
yamplum opened this issue Aug 3, 2023 · 13 comments · May be fixed by #1415
Open

Bring non-interactive screenshot options to parity with interactive ones #1065

yamplum opened this issue Aug 3, 2023 · 13 comments · May be fixed by #1415
Labels
help wanted needs discussion Needs discussion on how to implement or fix the corresponding task new api This requires adding API to an existing portal portal: screenshot Screenshot portal

Comments

@yamplum
Copy link

yamplum commented Aug 3, 2023

Hi. I was looking into building a screenshot tool for Wayland similar to Flameshot, and it's my understanding that I would use the Screenshot portal for that.

When I experimented with some prototypes, I noticed that the "silent" method call (with interactive: false) significantly lacks in features compared to the interactive one. On my DE (KDE), the interactive dialogue allows to select the screenshot region, whether to include the mouse cursor, set a delay, etc., none of which are available to the other version.

This is perhaps fine for applications that just want to "take a screenshot" and don't particularly care about how it's handled, but it's very inconvenient for writing custom screengrab tools which obviously do care a lot.

The screen capture tools on Linux still lag behind the equivalent solutions on Windows (such as ShareX), and it would be helpful to have the infrastructure in order to improve on that. Would it be possible to expose some of those interactive options on the D-Bus interface to bring the methods up to parity?

I found prior discussion about this in #139, and it seems like there was some initial interest in pursuing it. Would it make sense to restart the discussion?

@orowith2os
Copy link

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.

@yamplum
Copy link
Author

yamplum commented Aug 5, 2023

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

@orowith2os
Copy link

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.

@yamplum
Copy link
Author

yamplum commented Aug 5, 2023

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.

@orowith2os
Copy link

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.

@Mikenux
Copy link

Mikenux commented Sep 5, 2023

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

@GeorgesStavracas GeorgesStavracas added help wanted new api This requires adding API to an existing portal needs discussion Needs discussion on how to implement or fix the corresponding task portal: screenshot Screenshot portal labels Oct 5, 2023
@Play-InTheWay
Copy link

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

@Play-InTheWay
Copy link

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.

@Mikenux
Copy link

Mikenux commented Apr 1, 2024

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.

@DarthGandalf
Copy link

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.

@Mikenux
Copy link

Mikenux commented Apr 1, 2024

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).

@KelvinNovais
Copy link

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.

@Mikenux
Copy link

Mikenux commented Sep 13, 2024

@KelvinNovais: See #1415

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted needs discussion Needs discussion on how to implement or fix the corresponding task new api This requires adding API to an existing portal portal: screenshot Screenshot portal
Projects
Status: Triaged
Development

Successfully merging a pull request may close this issue.

7 participants