So much is written about Wayland not "being ready." I've used it exclusively on my desktop and laptops for... as long as it's been available in Ubuntu. It works fine. I don't have any issues with input methods. It puts pixels on my monitors. The screen doesn't tear when I move windows around like X did. It's fine for me.
I'm going to ask this in every thread.<p>Have we (those who are not paid to work on this) "followed the money?"<p>The glacial Wayland rollout to usability (it was AT LEAST a decade, don't try to fight me on this) is just so <i>odd</i> to me; to the point that I feel like it would be useful to examine the most powerful entities in this.<p>It's just really hard for me not to at least consider: Was the push for Wayland in the hands of entities who perhaps didn't have a particularly strong interest in a classically useable desktop? As in, a combination of entities who really have no interest in a Linux desktop (Ubuntu, who lets be real, has caved to Microsoft) or entities that are trying to hard to be cool and in doing so broke stuff that just works? (Lookin' at you, gnome?)
<i>"Conclusion<p>A lot of people say that X is slow because it’s a communication method, and it’s also outdated, buggy and difficult to maintain. However, from what I know about Wayland, Wayland is also a communication method, and Wayland is weaker than X in terms of functionality, so it is not suitable for desktop use. Although it has been 14 years since it was released, there is little progress in protocol development, and there are a lot of bugs in implementations. Moreover, the performance of the implementation is no different from that of X, the quality is below expectations, it is unstable, and the development maturity is low. Also, Wayland input method v1 and wlroots input method v2 are technically and functionally regressive to XIM that appeared in the 1990s.
Simply put, Wayland in 2022 is more technologically obsolete than X. Many people have been interested in Wayland and have been cheering for it, but Wayland seems to have no hope. How can there be no books published on the subject of Wayland programming in 14 years? If each Linux distribution accelerates the migration to Wayland, users will ditch the Linux desktop. I look forward to seeing a new display server to replace Wayland.<p>Thank you"</i>
Anecdotes as a Sway user and formerly i3 user.<p>I have a Compose key (RAlt on my current laptop). It behaves inconsistently across apps, because that stuff is implemented <i>in each app</i>, and they’re not implementing the same functionality.<p>Some ambiguous sequences are interpreted one way in one program (e.g. <-> = ↔ in Alacritty) and another way in another (e.g. <-> = ←> in Firefox). Order and whether includes are involved may or may not influence these things.<p>And I’ve come across one or two programs (generally your do-things-from-scratch, pure-canvas sort of things) where the Compose key just didn’t work at all. And I’ve encountered more than one or two web apps where the Compose key is basically broken.<p>(In general, Compose seems to be handled the same way as IMEs—speaking as a user, not a developer. Pressing Compose in GTK apps inserts an underlined ·, which is then replaced with the characters of the sequence as you type, underlined, which is then finally replaced by the resolved sequence when you’re done.)<p>All this was a problem under X. It’s still a problem under Wayland. It’s not a problem under Windows with WinCompose: <i>it</i> handles it all, not each app; so you don’t get any progress indicator (no underlined · or anything, it just consumes the keystrokes until you finish a sequence), but it all behaves consistently between apps, so long as they run as the current user. (That is: “run as admin” and WinCompose’s hooks don’t apply so the Compose key just doesn’t work.)<p>As for input methods in general… ugh, I recall the trouble I had under i3 with xim and ibus and whatever the other *im things were, it was even more inconsistent than I think I’ve observed under Sway. I don’t remember altogether why or what I did, and I haven’t tried doing exactly the same thing, so maybe it is actually about as bad as ever. But I <i>do</i> know that I’m generally finding a much better experience of input-related stuff under Sway than under i3. I haven’t had to tweak GTK_IM_MODULE or QT_IM_MODULE or XMODIFIERS environment variables or whatever other things for years.<p>Hmm… I also remap Caps Lock to Backspace, and I’ve noticed a couple of apps (e.g. Chromium, no idea if XWayland use is a factor) failing to handle repeat on that key. Little niggles like that aren’t uncommon, again I think there’s too much being left to the apps rather than being handled by the compositor or whatever.
I disagree with many of the conclusions about protocols. It does lead to some counter intuitive results, but if you want backwards compatible interfaces, you should indeed implement each version of the interface. For something like an input method, having the constraint that new versions of the protocol must be backwards compatible would be highly problematic. Having display servers and input method buses implement the versions of protocols that people use would be the best way to go, as it still means that input methods and applications themselves do not need to deal with this bifurcation.<p>Another highly misleading aspect is pointing out how many years Wayland has been in development. It's true, but it's not like progress has been linear. A vast majority of the Linux desktop ecosystem has been on NVIDIA graphics cards. I reckon Google probably has one of the largest deployments of Linux workstations internally and I believe they've only just begun the transition into Wayland. Thus, it should not be surprising that say, Chromium, has been behind on Wayland support.<p>While I empathize with people who think that the Wayland transition has been very expensive and slow, I don't really know what the alternative is supposed to be. There WERE and ARE some competing options. There was DirectFB, Mir. Arcan still exists. Probably others. Wayland gained mindshare as the baseline protocol for windowing, and here we are.<p>Will it fix everything wrong with the Linux desktop? Well, no. However, the painful irony of this post is that practically nobody uses XIM anymore due to limitations, they use out-of-band input buses. So each toolkit has its own plugin architecture for input buses, and then each input bus needs to have plugins for each toolkit, and you need to have the input methods themselves ported onto these. Note that you can also still use this approach if you want to in Wayland, especially important since Qt has been slow to adapt to protocol evolution lately.<p>All I can say is, it ain't going to be finished tomorrow, but a lot of what Wayland does really is architecturally a step in the right direction. There are some inherent downsides to the approach, but it also TODAY, right now, solves a lot of practical problems that users face that are hard blockers.
So is there a project/protocol that everyone can get behind?<p>If what is claimed here is true (wayland is a bad protocol) that might help explain the slow development.<p>I mean hackers might not like doing the boring stuff, but they'll do even the boring stuff on a project that's exciting, technically innovative or excellent, etc.
For all y'all saying "I'm still using X because Wayland isn't ready"... this is your reminder that X is DEPRECATED. The entity committing resources to maintaining it -- Red Hat -- has abandoned it and committed to Wayland only going forward. Unless another entity steps up with funding, X is doomed to bit rot and Wayland is the future. The responsible thing to do is to suck it up, file bug reports, and write code and/or documentation to improve the Wayland side of things because that's where the money and developers are -- period.<p>(And before you slag off Red Hat, remember that they are the Atlas holding up the entire Linux userland ecosystem for the past couple decades or so now.)
The reality is there's no method that I know of to grab window titles. These window attributes often play a role for accessibility and automation.