If Wayland is the future, the future is grim. People often complain that Wayland is taking a long time to catch up to X11, but that actually stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11. Even worse, Wayland does not standardize on or is hostile to some essential features, meaning that users need to rely on compositor specific behavior for those features, if they are even available. E.g., an application that needs to grab the entire screen will need separate code for each compositor it supports screenshots on, or it must use a protocol outside Wayland to get the screenshot. Quoting Red Hat:
> Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.
An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely:
> It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it.
But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
[0] https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...
> These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile)
That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users. But allowing programs to constantly take in arbitrary input & output information in the background, as well as simulate arbitrary input to other programs, is an obvious and glaring security flaw. Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground.
>Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them.
I appreciate that the average HN poster, and to a lesser extent the average Linux user, does not do this - but many, many Windows users do. In order to actually break into a mass desktop market, there has to be consideration of the ways people who do not currently use Linux behave.
I would even argue that lots of current Linux users are guilty of this - how many Arch users are checking the contents of PKGBUILDs from the AUR? How many Linux users, when searching for the solution to some problem with their desktop, have blindly copy-pasted commands from some support post - or worse still, just downloaded a "fix it" script to run?
Wayland is built on sane assumptions, because it also aims to cater to a not-insignificant part of the desktop market. That the response of an X11 supporter is "simply run the correct programs" show how little they have understood the goals and successes of Wayland as a project. It is not X12, and some of us are grateful for that.
> That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users. But allowing programs to constantly take in arbitrary input & output information in the background, as well as simulate arbitrary input to other programs, is an obvious and glaring security flaw. Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground.
Of course there's a middle ground: require special permission for programs that wish to do those things. For example, macOS has permission prompts for "[Application] would like to record this computer's screen." and "[Application] would like to control this computer using accessibility features."