He could have just moved the maintainership to someone else. I was wondering if there was something that triggered the decision is all. I wasn't trying to be snarky or mean, I just wanted to know what had cause the burnout.
It’s simple open source economics: Since no one is being paid to maintain the software, there is little incentive to continue developing it. However, since it is open source, anyone who feels inclined to can fork the code and create a maintained branch.
Just taken at face value, it looks like they didn't want to put in the significant effort of moving to newer display stacks. Wayland has a very different story for screen recorders, in ways which are likely to require significantly more ongoing effort.
Which I'm not sure I understand fully since I was under the impression that Green Recorder was pretty much created for the singular purpose of supporting GNOME+KDE/Wayland.
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.
Yes, except that wayland would have been the proper place to expose it, but they declined because it would supposedly compromise security (spoiler: to reach that interface, you must already have arbitrary code execution). So every compositor is now faced with reimplementing that same wheel on their own - each exposing their own interface somehow.
Okay, there's a lot to unpack here. First arbitrary code execution doesn't really matter. We're talking about a client-server relationship. Just because you have arbitrary execution on your laptop doesn't mean my server's security is compromised. And just because you have arbitrary code execution in a sandbox, container, flatpak, VM, or other host and can talk to my compositor doesn't mean it's compromised.
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.
Sorry, you are wide off the mark. Arbitrary code execution is game over because performing privilege escalation is usually prettyntrivial after that. Also, wayland is just a local IPC protcol.
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.
Skeptcism can be good, but not in excess. If you decided to respond by saying "In your opinion(s), what led them to close shop?", folks would have responded more kindly.
reply