Source: Hacker News
Article note: "Your established usecase is wrooong! Supporting it would be inconsistent with purely-theoretical future UI modes!" again from the Wayland camp.
These days I basically hope we get a PipeWire to Wayland's Pulseaudio. PA was "the ultimate solution" and always horrible even though it lingered for years, but it paved the technical and social way for a good (and compatible) successor, and showed where the problem points would be so the successor actually _did_ solve the whole problem space and more.
The Wayland folks have made some terrible-looking choices, largely related to getting burnt on supporting haphazard extensions forever on X... why is why the "do everything in extensions that we'll spend a decade arguing about before giving in and supporting what was initially asked for, just restricted enough to be awkward for every program that uses it forever" design was probably a bad decision. Also around the lack of a reference compositor library (but that's probably the same thing eg. xlib). Also around things like punting on input plumbing (yes, slipping into the kernel input layer with keyd virtual devices mostly works for hotkeys and remaps, but that's hacky. No, there still isn't an elegant way to pipe text to a specified window. Yes, those should be the same feature, and should be standard across compositors with one protocol.).
It's possible there's going to either be an "un-blessed" rogue extension suite that allows a bunch of "unapproved" behavior but every useful compositor has to implement because so much desirable software assumes its presence, or a shim/protocol filter/interceptor thing that sits behind/between/around the compositor to do the critical stuff that has been deemed 'wrong.'
Comments 