Exposing the Wayland lie (2018)
Thank you.<p>From what I&#x27;ve seen, Wayland seems to follow a very narrow set of use cases, and willfully ignores others outside its philosophy, no matter what their practical applications might be.<p>From what I remember reading previously:<p>- Wine is unimplementable in Wayland. By design.<p>- Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent&#x27;s hotkey tool to set global hotkeys. (Desktop enviroments may provide APIs for this, but then you get the foreseeable issues with using e.g. KDE apps on Gnome. And what if you don&#x27;t want a desktop &quot;environment&quot;?)<p>- Screenshotting and screen casting tools are unimplementable in Wayland, by design.<p>- Some Wayland implementations provide additional features, like screenshotting &#x2F; hotkey registration, anyway, as API extensions. These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation.<p>- I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop&#x27;s screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great.<p>I can certainly think of situations where Wayland&#x27;s advantages greatly outweigh its drawbacks, but its philosophy seems so much at odds with at least the way I interact with my computer, that the idea of switching to Wayland seems completely unfathomable. As far as I can see, at this rate, Xorg will live forever.<p>I&#x27;ve been instead working on my own little tool to fix the few annoyances in Xorg clients that I ran into (the ease with which I&#x27;ve achieved this and the flexibility of the tool speaks further in Xorg&#x27;s favor):<p><a href="https:&#x2F;&#x2F;github.com&#x2F;CyberShadow&#x2F;hax11" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;CyberShadow&#x2F;hax11</a>