Wayland Support

[xrishox]

The screenshotting tool doesn't work under wayland. I'm not sure if the audio capture does. At this point all major desktops are shipping wayland by default: Debian, Ubuntu, Fedora etc and wayland use is going to continue to grow from here. I'm not sure if it's feasible or possible, but wayland support would be absolutely awesome.

[eshrh]

Not sure why I didn't respond to this earlier, but I agree that wayland support would be super awesome! I also think that pipewire will probably be the future, following pulseaudio, so writing a branch of this that works with wayland/pipewire would be a great idea. However, I don't personally use either of these (yet), but I'll try to take a look at making it work soon. In the meantime, if you're willing to write a patch or a fork, I'm very open to it

[LunaGNUisance]

Some notes on where to start:

• If you use Sway, then writing a version of ames specifically for this WM should be easy. You can use grim, slurp, and swaymsg to get screenshot(), again() and screenshot_window() working easily. Here are some pointers on using these tools for screen capture: https://wiki.archlinux.org/title/Screen_capture#Wayland
• If you use GNOME, then you can't use slurp (GNOME's compositor doesn't support the zwlr_layer_shell_v1 protocol so slurp won't work), which means you'll need another solution for again(). The easiest way to get screenshot() and screenshot_window() working on GNOME is using gnome-screenshot -w and gnome-screenshot -a.
• record() needs to be rewritten on Wayland for me as it doesn't work in its current state. Not sure if this has something to do with pipewire; out of my depth. And I haven't been able to find a Wayland tool that records just audio.

[eshrh]

Neat, thanks. I was toying with the idea of just rewriting the program in pure python, using some lib to take screenshots and record audio. Maybe that would be a better option?

I now do use pipewire-pulse on X though.

[tatsumoto-ren]

If you can avoid python, don't use it. Use it if you can't.

[LunaGNUisance]

Not sure why record() didn't work at the time I submitted the initial comment. It works fine in both a GNOME and Sway Wayland environment for me now.

I rewrote ames to support Sway (and maybe other wlroots compositors eventually). In the end, I did not have to make many changes and everything works fine for me on Sway: https://github.com/LunaGNUisance/awes/commit/08b43580b945d9bff6b02f9ecaf6c29e956a2260#diff-da5eaae48b21f956e1e77a2716d7040f872db565a2b92ca2c2f0623cacdcf3a7

The additional dependencies pulled in are slurp, grim, jq, and wl-clipboard, which also replace some X11 dependencies used for the same purposes.

awes could be easily re-written to accommodate other Wayland compositors such as GNOME by using gnome-screenshot instead, and probably kwin too. I didn't see much point submitting a pull request as I simultaneously deprecated support for X11.

[eshrh]

neat, and thanks! I mean, I'd prefer it if you would open a pull request to a new branch on this repository, and I'd add you as a collaborator with push access. If you don't want to, which is totally fine, I'll just edit the readme to include a link to your repository. Let me know what you'd like to do!

[LunaGNUisance]

@eshrh Sure, I'm happy to create a PR if it's useful to you. I've done so now. I couldn't find a way to create a new branch in this repository, presumably because I'm not a collaborator (this is my first pull request). I've targeted the PR at master for now with the expectation that a reviewer will create the target branch and merge the changes into it.

[eshrh]

I'm going to leave this issue open just because it doesn't sound like the new wlroots works for every wayland compositor.

[LunaGNUisance]

The options that work on all Wayland compositors (as far as I'm aware) are -r and -c, provided the right dependencies are installed, as -r uses only ffmpeg and pulse/pipewire-pulse to record audio, and -c uses wl-clipboard, which seems to be supported by all compositors.

Implementing -s, -a and -w reliably for the Mutter, kwin, and Sway compositors in one script is challenging. gnome-screenshot is supported by Mutter/GNOME, but not wlroots compositors. grim/slurp are supported by wlroots compositors, but not GNOME. GNOME has no interest in supporting the protocol extensions that grim/slurp use:

GNOME Shell has NACKed our protocols, so they won't implement it. Other compositors like KDE are potentially interested.

flameshot seems to be the only screenshot tool that works for all three (it uses grim for wlroots compositors), but it requires some setup on wlroots compositors: https://github.com/flameshot-org/flameshot/blob/master/docs/Sway%20and%20wlroots%20support.md

I haven't been able to get flameshot to work on Sway yet. From my understanding, if you wanted to target all compositors with a screenshot application, the only method would be through xdg-desktop-portal using pipewire. flameshot seems to be the only project to have done this.

However, as a result of relying on D-Bus to do so, it requires extra setup on wlroots-based compositors. Flameshot also does not allow the user to screenshot the active window, meaning there is no way to implement -w. It also means pulling in more dependencies than the far more minimal grim/slurp/jq combo. The last issue is that, on GNOME, it will prompt the user every time to grant flameshot access to the screen to take a screenshot: https://github.com/flatpak/xdg-desktop-portal/issues/649

It seems that GNOME has no objections toward fixing this, though no one has done any work toward it yet—but at the very least, we shouldn't expect that last issue to stick around for long.

This leaves us with a few options to support all these compositors:

• Maintain a separate script/AUR package for Mutter, wlroots, and kwin. The required dependencies would be correct for each package and keeps each script as simple as they are now. However, it would be more work to maintain and propagate the latest changes across all scripts.
• Combine all cases into one script. This would probably require setting a variable in config such as COMPOSITOR with valid values of mutter, kwin or sway or adding a --screenshot-tool option that a user can pass. The dependencies would then have to be set as optional, using gnome-screenshot, jq, slurp, grim, and flameshot. More easily maintainable, but requires more user intervention.
• Rewrite it in Python. I don't know Python myself, but this might be the cleanest solution. Based on this answer: https://stackoverflow.com/questions/72216896/how-can-i-get-a-screenshot-on-wayland-with-pure-python You could make the dbus call to take a screenshot using xdg-desktop-portal for every compositor. It doesn't need to have as many features as flameshot, so fewer dependencies will be required for both the user to install and to build. It would probably be the simplest and most reliable solution. However, I imagine most Sway users would prefer to use slurp and grim, and to support -w on Sway, I believe you would need to have grim as a dependency.

No matter which we choose, this would still leave us without support for -won kwin and other wlroots compositors, but there's not much to be done about that on our side. I don't think this is really that much of an issue, as using -s (and selecting the active window) and then -a repeatedly achieves a similar effect. But it would be nice to eventually implement this once it is supported as part of some protocol extension that every compositor implements (yeah, right).

I'm partial towards maintaining separate scripts given my lack of Python ability and the simplicity of installation for users. But I'd like to know what you think, @eshrh

[eshrh]

Thank you for spending so much time to look into each of the compositors!!

The more I read about this, the more I feel myself leaning towards rewriting in python. However, if the primary benefit of this is to support gnome and kde, and this still requires user confirmation, I don't think it's worth it. Kind of the whole point of ames is to allow a handsfree keypress -> full automation workflow. I'm quite familiar with python and totally willing to rewrite it though.

I already sometimes forget to update aur packages, so I'm definitely against adding an aur package for each script unless you're willing to take responsibility for it. While ames feels mostly "finished" in a sense, any changes would have to be merged across each branch.

For now I'm not particularly happy with either for right now.

I think your idea with having the user set binaries is actually a pretty great idea. I'd have to figure out the details with aur packaging and optional deps, but i imagine we could expand this to support customizing selection tools and perhaps even the binary used to record audio. I think we can manage two aur packages, one for X (so no optional deps), and one for every wayland compositor that allows the user to set their preferred binary.

I don't think gnome-screenshot uses the same -g geom pattern though, so we might have to allow the user to customize the whole command used to take the image, which sounds nastier.

If we end up going this route, then I'd much prefer setting individual binaries rather than setting some kind of COMPOSITOR option.

This has been an Interesting insight into the state of screenshotting on wayland... let's think it over for a little while before doing anything else though.

[LunaGNUisance]

It was an interesting learning experience for me, too. As far as I can tell, this problem stems from the Wayland protocol not specifying a method of screen capture and leaving that up to protocol extensions—which is not necessarily a bad thing in itself—but Wayland compositors can't agree on what protocol extensions they should support.

For now, though, the only Wayland compositor that has support for all the features ames offers is Sway. It also requires very few dependencies and works in much the same way the original Xorg script did. That ames-wlroots script is a drop-in replacement for any ames users; all they need to do is install grim, slurp, jq, and wl-clipboard. So I would consider it 'complete'. The issue is adding support for GNOME and KDE.

I already sometimes forget to update aur packages, so I'm definitely against adding an aur package for each script unless you're willing to take responsibility for it.

Fair point. It might be harder to write an all-in-one script, but I agree it's a good idea.

However, if the primary benefit of [rewriting it in Python] is to support gnome and kde, and this still requires user confirmation, I don't think it's worth it.

KDE doesn't require user confirmation—just GNOME. But I agree that it's a considerable amount of work for something not that much better than hacking around the problem in bash. This would only improve the situation for KDE, really.

but i imagine we could expand this to support customizing selection tools and perhaps even the binary used to record audio.

What did you have in mind for an alternative audio-recorder? At least on Wayland, I think ffmpeg is the only thing that can record just audio. And the script works without alteration on pipewire-pulse.

I think we can manage two aur packages, one for X (so no optional deps), and one for every wayland compositor that allows the user to set their preferred binary.

This sounds logical to me.

I don't think gnome-screenshot uses the same -g geom pattern though, so we might have to allow the user to customize the whole command used to take the image, which sounds nastier.

Right, that completely slipped my mind. I think the only way to implement again() on GNOME would be to use flameshot for both screenshot() and again() and gnome-screenshot for capturing the active window. I think if the user really wants to do this, they should be able to by using the -t option to select the screenshot tool for just that command, but I don't really want to support that as an "official" solution.

As of GNOME 42, a screenshot tool has been integrated with the shell. I think it would be possible to implement screenshot(), again(), and -w with just this one tool, but I have no idea how to access the screenshot tool with bash—if it's even possible.

One solution worth considering is implementing an option to update the latest note with the most recent screenshot in a directory. This way, the user would take the screenshot manually, then use ames --grab-latest-image to update the note. See an implementation I wrote a while ago for grabbing the latest audio for more details on how this could work: https://github.com/LunaGNUisance/ames/commit/64ab46adee58cb52ac54a7cf5be040b1a89f3307

It's not a great solution given the need for manual intervention, but it means a GNOME user can use the built-in screenshot tool to access all ames features, so I don't think it's a bad solution, either.

KDE

I found out that KDE does actually support slurp for getting the geometry, but not grim for actually taking the screenshot, so this isn't helpful. KDE already installs most of the dependencies flameshot needs, so I think flameshot would work well for implementing most ames features.

---

My suggestions would be to:

• have one wayland script that supports all compositors and one AUR package
• create a SCREENSHOT_TOOL variable
• implement a -t option that sets SCREENSHOT_TOOL equal to the argument
• create if statements that take a screenshot using different options depending on the SCREENSHOT_TOOL, because all the options are wildly different for each tool (gnome-screenshot for GNOME, flameshot for KDE, grim for wlroots compositors)
• identify recommended tools for each compositor in the README

[eshrh]

This should be solved by recent changes that make it possible to override any function of the script in config. Check out contrib/wayland or contrib/python for config files that should work cross-platform.

[stephen-huan]

My suggestions would be to:

• identify recommended tools for each compositor in the README

I agree this would be nice to have. Currently contrib/python contains a screenshot program based on pyscreenshot and corresponding config which should work on every Wayland setup without additional configuration (pyscreenshot claims to work on GNOME, KDE, and Sway and has support for grim and gnome-screenshot as backends). However, although pyscreenshot can screenshot a geometry (region), it has no concept of a window so an external program needs to be used to find the geometry of the current window to support screenshotting the current window (-w). For example, on X one can use xdotool getwindowgeometry and on Sway one can use swaymsg -t get_tree. I'm not sure what one can do on a non-Sway Wayland compositor. Also, shell minimalists might want a "out of the box" config using their compositor's corresponding command line binaries (directly calling gnome-screenshot instead of going through Python for example).

If anyone is so inclined, feel free to contribute contrib/{compositor} if you have something that works for you (that's what contrib is for!). Both eshrh and I are on X11, so it's a bit difficult to test these ourselves.

[xrishox]

gnome-screenshot works for gnome under wayland and the kde equivalent would be spectacle. they both have command line interfaces. it doesn't list spectacle for pyscreenshot but maybe kde can use grim. grabbing the current window is a nice to have, but it isn't that important as long as region works.

[tatsumoto-ren]

I used to use gnome-screenshot on i3wm. Though it's not a wayland WM, I would assume gnome-screenshot works under any environment.