Goodbye, Green Recorder
github.com
github.com
It's a community that aims to help take care of OSS projects when the maintainer no longer can.
It's also free, isn't it? And therefore a very viable alternative to the vat majority of users
Sorry this got taken the wrong way.
I'm surprised that GNOME and KDE dropped the ball on this since all they had to do was provide a stable dbus API and any app would be able to consume it with very little fanfare.
The security model for Wayland is that it should enable you to create secure systems if you wish to plug the rest of the holes. You can't really use Xorg in a secure system because being able to talk to the X server at all exposes too much privilege.
Screen recording (and taking screenshots) is a bad fit for the Wayland protocol because then what is a very small and lean protocol suddenly needs to know about things like image and video encodings. And since it's a display-only protocol you either have to teach Wayland about auto streams and mixing or stitch together your audio out of band.
But fine, we somehow all agree that such things are in the scope for a display protocol. Recording your screen is still a privileged operation and Wayland doesn't have an authentication or permissions system. How should they authenticate? In a way that a malicious program can't fake?
We end up just reinventing dbus, polkit, pulseaudio, pipewire but in a way that ensures that you can't swap out those components for something else.
If you care about standardization then it's really not that bad: GNOME and KDE typically work in tandem when desiging dbus interfaces and smaller DE's end up implementing those. So far the world hasn't ended for media controls and it won't end for screenshots.
To be more precise, its graphics related part is a GPU buffer management protocol only. No graphics data is passed between processes through that channel. All that happens is buffer allocation and buffer access brokering. This ties into what the wayland part of a screen capture tool is: read access to the frame buffer after composition. No image encoding, no video codecs or anything else, just the ability to get to the raw pixels.
This also means that sound is a non-issue for wayland because the audio stack is separate.
Also, I remember that adding authentication prompts to compositors was seriously comsidered when screen capturing came up on the wayland mailing list. IIRC it was only rejected because it created weird synchronization issues because of the unspecifies time interval between the request by an application and the response by the compositor. And I seem to remember that there are some compositors who allow whitelisted applications to perform operations that are comsidered privilieged.
Anyway, I consider a display server that doesn't allow an application to query window positions and acreen resolutions and forbids explicit window placement to be broken as far as any serious GUI apllications are concerned. This combination of restrictions makes implementing features like sane tooltips and context menus impossible.