-
-
Notifications
You must be signed in to change notification settings - Fork 194
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
Comments
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. |
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 |
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. |
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. |
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 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. |
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:
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. |
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:
|
I agree with the idea. Exposing directly the |
@KelvinNovais: See #1415 |
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?
The text was updated successfully, but these errors were encountered: