Xorg also doesn't prevent you from using an application that does have these functions. Wayland does prevent you.
> but it's perfectly possible to write without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi).
The necessary APIs don't exist, so it isn't possible to write the extra functionality without changing the compositor.
Honestly, I don't understand why anybody defends Wayland at this point. It's been, what, ~~six years? Six years~~ FOURTEEN FUCKING YEARS we've been telling you that we want to be able to use our screenshot and recording applications and that removing functionality that we use day-to-day wasn't acceptable. Are the Firefox devs the same people making Wayland? Is that why they're so unresponsive to user needs?
It's because Wayland is a set of protocols, rather than a single dominant implementation.
In order to do it right, cross-compositor and flexible, you have to get different actors with different interests and bandwidth agree on a standard. This takes time.
In order to get it working fast, developers need to make a compositor-specific implementation first and then put in the extra work of getting it through the standards discussion as well as switching their compositor ecosystem to the new standard.
Until this happens with all parts that you care about, you're going to be annoyed either about interoperability or functionality. Pick your poison, and cue Moxie's "The Ecosystem is Moving" blog post. Also, keep using X11 until Wayland has the features you want. Most DEs/WMs haven't ripped out X11 support yet, and hopefully won't until their support of Wayland protocols is solid enough.
However, the Wayland team is responsible for the set of protocols that they've developed and that they've asked others to implement. The Wayland team has failed to define protocols that are flexible enough to provide basic functionality that users expect, even if they were implemented perfectly.
This should not be a process that depends on individual developers building compositor-specific remote-desktop tools first, then praying that someone likes them enough to put it in the standard. Wayland built the standard, they just built an insufficient one.
If the Linux kernel had worked the same way, we'd never have gotten Linux.
Yes we would. In fact it's exactly how Linux works and has worked for decades. New features get added in drivers and then get rolled up into driver subsystems when enough hardware supports them.
Except they do exist and do work.
Surely, as much as seatbelts prevent my movement. And literally every wayland compositor has this functionality, that there is not a universally supported standard here sucks, but that’s just the way of life of the bazaar. There is no one company exerting a cathedral approach over the whole thing, and I believe that is what most of the linux users prefer. It just so happens to have some tradeoffs as well.
I believe that the only thing missing is capturing individual windows with screencopy. There's actually an issue for that and ongoing discussion on how to implement it. Nobody's decided it's a bad idea, it's simply a matter of nobody having done it so far.
Xorg never "implemented" this feature. It's just that any client can read what other clients are doing. So Skype can screen-scrape your password manager by default. Obviously this was not a good choice, so Wayland has dedicated protocols for this functionality, with the intent of restricting them only to privileged clients.
Finally, while no _standard_ protocol exists to address this, there are compositor specific ways of capturing a single window, so most users have their needs met.
You mentioned shotman, but that isn't even a real screnshotting tool: it's just a screenshot GUI that depends on existing functionality that may or may not be present in your compositor.
If all the compositors actually supported a standard for providing this functionality; and if that standard provided enough flexibility to do what I want, then I wouldn't complain. That's the essence of modularity. But the standards are poor and poorly-supported, and I literally can't do what I want. Your trivial example of using the sleep command to simulate delayed capture doesn't address the actual issue, and fails to recognize that no amount of hacky solutions will allow me to use a VNC screen sharing tool that shares only a specific window, because the Wayland compositors have chosen not to support that feature and failed to provide a standard way for external tools to do so.
Yes it does. Use the screenshot, screencast and remote desktop XDG portals for that.
In my use case, I want to screen share a specific window, not the whole screen; this is functionality previously provided by a third-party X11-based tool, which cannot be provided from an XDG portal (even on those compositors that support portal at all).
However, their implementation is not meant for native applications and are pretty inefficient. For example, the screenshot portal will save the image into disk and return its path -- so if you wanted to render the image on screen, you now need to read and decode a file. The screenshot is encoded, serialised to disk, serialised FROM disk and then decoded again just to get pixels from the compositor back into the compositor.
Portal really don't make sense if you're writing native wayland clients, since portals just really end up using the wayland protocol under the hood, with two or three services in the middle handing messages over just to expose a "standard" API.
Regarding the fact that GNOME doesn't implement a lot of functionality: I don't think it's fair to criticise the protocol and architecture because one implementation decides not to implement a given feature. This is like saying "C sucks because some specific compiler doesn't support the feature I need". It's the compiler you've chosen that sucks in that case, not the language.
I'm sure there's some X server implementation out there that's also lacking features you want -- but you wouldn't blame the protocol itself for that implementation's shortcomings.
Xorg doesn't support his either. Your screenshotting tool runs the timer and takes the screenshot when the timer expires. You complaint is like saying "the Linux kernel won't render markdown for me". No, it won't, you're looking at the wrong part of the stack.
For example, you can simply run `sleep 3 && shotman --output` to take a screenshot of an output in three seconds. There might be other GUI tools with a pretty timer setting. I've no idea if such a thing exists or not, but it's perfectly possible to write without any changes to the compositor (e.g.: the compositor provides the necessary APIs for thi).