That means the screenshot application is, to some degree, compositor specific. It leaves the door completely open to the outcome that if you want to stream using a Gnome streaming application you will have to be using the Gnome project's window manager. Or the KDE streaming application will require the KDE window manager. Or the 'best' screenshot application will be tied to the XMonad successor on Wayland.
Wayland is a good experiment, and the community may well go with it because X11 is atrocious and Wayland is a viable alternative. But call a spade a spade, they dropped the ball with that design decision. It isn't a big deal.
The practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as well. The required negotiation for that to happen is taking/going to take years and delay Wayland adoption. If they'd designed that at the same time as an optional part of the Wayland protocol it would have saved time and confusion.
> The practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as well. The required negotiation for that to happen is taking/going to take years and delay Wayland adoption.
Linux fragmentation is a real thing, but if the community is going to take multiple years to reach a consensus on the right way to approach screenshots, that does at least somewhat suggest to me that leaving it out of the base protocol may be a good decision. My understanding is that the point of Wayland is to be a semi-permanent solution to the problem of X11. Any mistakes we make in the protocol will haunt us for decades, not just years.
That concern makes me more likely to err on the side of reaching consensus before core logic is implemented, even though I admit that the fractured nature of the Linux community is likely to make process take a lot longer. I'm not saying that nothing should be standardized, just that if it looks like there's disagreement over implementation, it might be a good idea in this specific case to bias towards delaying a final decision.
The protocol mistake might easily be that they didn't include a security policy mechanism for coordinating Wayland buffers or something similar. It sure looks from the peanut gallery looks like they have a security model (graphical output is completely secret except to the compositor) that is insufficient in practice and users really want applications to be able to snoop on each other when required. That is going to be more difficult to tack on afterwards than it would have been to design in at the start. Security is exceedingly difficult to do after the fact.
Maybe they did consider all this and have a plan. But I havn't seen anyone write a "this is how you target arbitrary compositors with your toy screenshot program" article yet.
> Security is exceedingly difficult to do after the fact.
This is an odd application of that idea to me. In my experience it's not to terrible to punch holes in a system after the fact. Exceedingly difficult is patching the holes in a project that starts as Swiss cheese.
I think this is a misunderstanding of how screenshots work, and how Wayland has always intended to deal with the issue.
First of all, note that as with any window system, application buffers are not the final version of what you see on the screen. A normal desktop has wallpapers, transparency, task bars, multiple windows and window occlusion.
This means that apart from a few special cases, only the compositor knows how the full scene currently looks, and is the only entity capable of producing a buffer containing the entire thing.
For this reason, the only way to do screenshots is to have a way to ask the compositor for one. This is the case for any windowing system, and nothing related to buffer management will change that.
> ... that they didn't include a security policy mechanism for coordinating Wayland buffers
Depending on what you mean, this is either slightly or very untrue. Basically, when you try to present to screen, a client takes a buffer (which is private) and commits it to a surface. This temporarily borrows it to the server.
Should the server wish to share the buffer, this is when this would be done. Before doing so, the server would enforce any security restrictions as necessary. This is how all client-to-client communication happens in wayland: With the server as mediator, when it permits it.
A screenshot of a window or direct-scanout application could be implemented by simply having the server further borrow the buffer to a recording application, with appropriate restrictions in place.
> users really want applications to be able to snoop on each other when required.
I don't understand why you would think that this is a problem under Wayland. They only difference is that while X11 implicitly allows everyone to snoop on everything without any way to control it, snooping in Wayland is explicit, and servers can prompt users to permit it per application. Or not, it's up to the server.
> That means the screenshot application is, to some degree, compositor specific
This is not the intention under Wayland. Wayland protocol development is geared towards compositors implementing protocols for experimentation, and then basically "upstreaming" the result. Even before upstreaming, compositors share work (e.g. wlroots implemented at least one kde-specific protocol, that has now been superceeded by the resulting upstream work).
Also, all Wayland protocols are advertised in the registry, so applications don't do "I'm on KDE, so...", and instead just use the protocols available. It is therefore not a problem if KDE implements a GNOME protocol, for example. It'll just work.
Screenshot and recording will be a shared protocol, but due to wanting a proper protocol with goodies like damage tracking for performance, it's a little bit more work than you would think. We certainly don't want X's "dumb" approach—we want something faster and safer (that is, functionality guaranteed without tearing or fun stuff like that).
> The practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as well.
So we are going to reinvent X extensions from scratch? By the time that is finished we will have enough legacy bloat that people will call for the next replacement.
there are already a number of screenshot protocols (as TFA explains, slurp and grim can be used for screenshots on sway). the trouble is getting everybody to agree on a single one, or implementing a library to interface with all the protocols, which is the current strategy. https://www.google.com/search?q=wayland+screenshot+protocol
but, IMO, this is a good thing, and the only way it could have worked. if every single conceivable protocol was added to the initial specification, then wayland would never have been released. even if it was, people would complain even more about it being "bloated" and "non modular" and "not following the unix philosophy", whatever that means.
Screenshots, remote desktop stuff, etc, is being built under the Portal system that’s used for flatpak. GNOME and KDE already support this, and it doesn’t depend on flatpak at all.
freedesktop have had success in standardising the Linux desktop. I fail to see why gnome, KDE, etc wouldn't eventually standardise around a common screenshot protocol.
Windows switched to composited desktop with Vista in 2006 and didn't lose any[0] functionality. 14 years later and we're still saying "eventually" when discussing basic features Wayland should have.
[0] Technically it lost a few, the ability to ignore vsync for non-fullscreen applications being the biggest one.
Jokes aside, this has nothing to do with the protocol as much as the fact that there are vast differences in how an open source project is developed vs. how Microsoft develops.
A lot of Wayland development was initially funded by Samsung, which mainly focused on usecases for their smart devices. They then shut down their entire OSS department, so that workforce is out.
Now, finally redhat seems to be gearing up a bit, with GNOME Wayland being default on Fedora, and sponsoring Wayland work on things like Firefox.
But, even then, things are powered by what people want and care about, rather than just trying to tick every previous feature box available.
Many things that came out of freedesktop.org are pure garbage. The most prominent example is dbus. Personally I hope they have no success in standardizing anything further.
There are many ways to do IPC on a unix system. Dbus is a reinvention of IPC in the worst possible way. It requires a daemon to run and it requires every client to be able to parse and generate JSON. The worst thing is that those JSON packets are not even human readable most of the time. Protocols that are running on top of that are also not standardized. If you are lucky KDE and GNOME agree on something. Many times they don't.
Except that it was designed to be read into memory and directly accessed without parsing. A GVariant Array has the form of its elements and their lengths. You can index into an Array in linear time.
Wayland is a good experiment, and the community may well go with it because X11 is atrocious and Wayland is a viable alternative. But call a spade a spade, they dropped the ball with that design decision. It isn't a big deal.
The practical outcome is that there is going to be a screenshot protocol and everything that implements Wayland is going to have to implement that protocol as well. The required negotiation for that to happen is taking/going to take years and delay Wayland adoption. If they'd designed that at the same time as an optional part of the Wayland protocol it would have saved time and confusion.