is working without grim in scope for this project?

[jokeyrhyme]

I'm curious about what the vision/boundaries are for this project

If I get some time, I'd like to attempt to implement making a request to the Screenshot Portal API: https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot

And/or even making the various calls to the wayland socket directly?

This would make it unnecessary to have grim installed

But, it's totally fine, of course, if this isn't something you're interesting in adopting/maintaining :)

[Kirottu]

Implementing it inside Watershot is an idea I've had for a while, and there are a few ways to go about it.

We could implement it using the XDG portals, but at least for wlroots based compositors that wouldn't actually even eliminate the grim dependency, as xdg-desktop-portal-wlr just uses it to capture the screen.

Another way is implementing the wlr-screencopy protocol inside Watershot itself, which would eliminate the grim dependency, but would mean that only wlroots and Mir would support it.

How do you feel about these 2 paths that we could take?

[jokeyrhyme]

Looks like Flameshot only implements the portal and grim paths? https://github.com/flameshot-org/flameshot/blob/3ededae5745761d23907d65bbaebb283f6f8e3f2/src/utils/screengrabber.cpp

I'd suggest that we implement https://wayland.app/protocols/wlr-screencopy-unstable-v1 and https://wayland.app/protocols/weston-screenshooter (these are probably the most popular implementations) and probably leave https://wayland.app/protocols/agl-screenshooter for later

I'd also suggest that we do still implement a xdg-desktop-portal path, as well, as this should cover compositors that don't implement either of the above protocols

It could be useful to have an order of precedence/preference where watershot automatically tries them all until it finds one that works

If performance is the highest value, then it could make sense in trying the wayland protocols, then grim and then the portal?

[Kirottu]

If we implement the protocols ourselves, grim won't be required anyway as I believe it just uses the screencopy protocol. And yeah I think we should use the portals if other methods don't work.

Also, what compositors even implement the Weston screenshooter protocol? The protocol explorer reported no compositor support for the protocol.

[jokeyrhyme]

I assumed, from #8 , that weston only implements the weston protocol and not the wlroots one :shrug:

It could be that the data in the explorer is incorrect, or that my assumptions are incorrect :)

[Kirottu]

Yeah I'd also believe that Weston implements the protocol. But honestly I don't think I have ever actually seen someone actually using Weston as their primary compositor, and Watershot already wouldn't work on it due to needing the layer shell protocol.

So I feel like implementing the Weston protocol would be pretty redundant.

[jokeyrhyme]

It looks like smithay (the equivalent of wlroots but for Rust) doesn't plan on implementing any of these protocols, so that family of compositors (e.g. COSMIC) will have to provide their own xdg-desktop-protocol implementations (which is covered if we add portal support)

[Kirottu]

Hmm yeah it doesn't seem like it, so portal support is definitely also needed. Maybe we should try first creating a version with only portals and then see if implementing the screencopy protocol ourselves is necessary?

[jokeyrhyme]

https://crates.io/crates/ashpd seems promising

[Kirottu]

That crate does indeed look like it would implement what we need, the name is also fantastic.

[Gigas002]

I may be incorrect due to my complete lack of knowledge of how wayland protocol works, but isn't libwayshot looks like what we need? AFAIK it doesn't use grim, though it's application, wayshot, depends on slurp to take region values for screenshot. But it looks to me, that watershot does exactly what the slurp does for now, so these two may work out together?

I tried implementing it myself, but yet again, I don't have enough knowledge and experience of Wayland protocols, so the results were nothing.

UPD

I've got it working in my fork. Posting it here strictly for reference purpose (my code is shitty and dirty) just to let everyone know it seems to be possible. Should work like a charm, if someone who can do stuff good implements this