I disagree. The distro devs are pushing it because it furthers their mission, which on the face of it (for a lot of them) seems to be "ship software that works for people and have them stop bugging us".
> However broken the past was, replacing it with something that is similarly broken but in different non-overlapping ways is not the proper way forward.
That "opinion" is well founded. Most people don't care about network transparency (to pick one example), and those that do can club together and keep X alive. Or write an extension for Wayland. Open source is easy in that it gives you many chances and ways to contribute!
Personally, I'd prefer those "LOOK IT'S MY DESKTOP OVER THE INTERNET" people kept their weirdness out of my compositor, but that's just my take.
This is a strawman. There's a reason I mentioned color management in particular. Most people who aren't aware (even software developers) tend to make two assumptions:
- that color management is needed for a tiny subset of users (those weird guys with printers and calibrators...).
- that it can be delegated to 3rd parties or implemented later when the time comes.
Neither of that is true. Color management is just another word for correct rendering of everything that comes through your stuff. Every pixel must have a well defined path from the physical input to the application to the physical output, you can't just implement a part of it and move everything else out of scope. To display anything in HDR, you have to build your entire pipeline around color management from the ground up.
The reason you are ignoring it is that you're using an sRGB display, in any other case it would be immediately apparent to you. sRGB also needs color management but everything assumes sRGB so you're able to mostly get away with it. This no longer holds in the modern hardware. You need a properly managed pipeline for gaming, movies, web, YouTube, GUI, smartphone family photos, and basically everything else.
Wayland developers actually found it the hard way, and are trying to implement it for, what, 3 years? That this wasn't a feature of a display server protocol from the start is a massive design flaw.
Same with the input methods handling being forced to be lumped up together in the downstream software, without at least specifying how it should be done. They took a well understood problem, and moved it out of scope; it might not have been an issue, but the lack of a spec will lead to fragmentation and less options. This affects most of the userbase, not "weirdos with remote desktops".
The vast majority of linux desktop computer users are likely using sRGB displays to look at things in the sRGB colourspace.
Should colour management be in Wayland? Sure. Could it have been designed better to cater for it? Absolutely. Wayland's got its warts, sure. But for most people it's good enough, and that's what matters in software. It'll get fixed, and the more people who care about it actually contribute, the faster it'll get fixed. Open source is amazing!
- Alternative / switchable / tunable keyboard layouts and input methods. Not fancy stuff, just, say, typing Latin, Cyrillic, Greek, and Japanese characters.
All these things are is some sort of disarray under Wayland currently. Once they are properly implemented, I may consider switching.
I want Wayland to succeed. But it's not entirely there yet.
I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
> Alternative / switchable / tunable keyboard layouts and input methods. Not fancy stuff, just, say, typing Latin, Cyrillic, Greek, and Japanese characters.
I use global hotkeys to switch between keyboard layouts, see the screenshot. Works fine.
> All these things are is some sort of disarray under Wayland currently
This all basically worked out of the box. I'm really not seeing where this disarray is. Have you actually used wayland, or are you regurgitating taking points from 5 years ago?
You've moved the goalposts on this argument now. "$Thing is hard to implement on Wayland and requires quite a lot of effort by each DE"[1] is a very different argument to "$Thing doesn't work on Wayland". Pretty much everything you listed works well in Fedora with Gnome/Mutter.
If the maintainers of the DEs are happy with the effort, then I don't see a problem? (unless you're a DE maintainer, in which case - fair enough).
[1] When I first wrote this sentence I wrote "X is hard to implement" using X as a metasyntactic variable before I realised that was incredibly confusing in context!
If something requires effort from each DE / compositor to implement, it's not "implemented in Wayland", but rather Wayland does not preclude it from being implemented.
It's worked fine for X for decades now, so simply claiming "it's not a solution" is kind of silly.
I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry.
Also do keep in mind this is about more than global hotkeys; there are several accessibility paradigms that simply don't and can't work on Wayland.
> It's worked fine for X for decades now, so simply claiming "it's not a solution" is kind of silly.
It never worked "fine", it was always a failure from security and usability perspective.
> I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry.
You know that apps have security vulnerabilities that can be exploited over the network? Screen grabbing, keyloggers, input injection(you have open root terminal? let's type some commands there). And more.
As I have said many times, a good intentioned program with a bug only needs bad intentioned data.
A malicious PDF file is enough to break havoc with a simple memory bug, so unless you claim that open source is also bug-free, or that you don’t use any external data (but visiting this site already invalidates that assumption), then you are just being naive.
There is nothing inherent that couldn’t work with Wayland - there is nothing preventing the relevant teams agreeing on a new interface to broadcast accessibility information to the wayland server, that can thus share that with specific accessibility software (which is explicitly permitted to do it).
> I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry.
Do you personally audit the source code to every piece of software you run on your computer? Do you have the expertise necessary to even do that if you wanted to?
FOSS isn't magically immune to security exploits. Everything we build should assume any other software it interfaces with might be defective or even hostile.
You're not really addressing my argument here. Of course Wayland users don't audit the Wayland source code.
I was illustrating why Wayland's security paradigm is important. It doesn't assume all the apps it renders are safe. It can still (and probably does) have security holes, but it is already starting from a much more secure foundation than X11 ever had any hope of having.
Similarly, my web browser probably has not publicly known exploits that I haven't bothered to discover myself, but that doesn't mean I should be OK with using a browser that doesn't sandbox its javascript engine.
It is more than event routing, you do not really want for any client to be able to claim any combination, without any further insight by either compositor or user.
Ideally, what you want, is for the client expose a set of (described) actions, with suggested key bindings. Users can then enable / disable / change the bindings in some central place, which would also take care about collisions, reserved global keybinding or reserved local keybinding (key shortcuts, that are always supposed to be available to the focused app).
> However broken the past was, replacing it with something that is similarly broken but in different non-overlapping ways is not the proper way forward.
That "opinion" is well founded. Most people don't care about network transparency (to pick one example), and those that do can club together and keep X alive. Or write an extension for Wayland. Open source is easy in that it gives you many chances and ways to contribute!
Personally, I'd prefer those "LOOK IT'S MY DESKTOP OVER THE INTERNET" people kept their weirdness out of my compositor, but that's just my take.