The reality of Wayland input methods in 2022 (2022)

Have we (those who are not paid to work on this) "followed the money?"

The glacial Wayland rollout to usability (it was AT LEAST a decade, don't try to fight me on this) is just so odd to me; to the point that I feel like it would be useful to examine the most powerful entities in this.

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?)

Thank you"

I have a Compose key (RAlt on my current laptop). It behaves inconsistently across apps, because that stuff is implemented in each app, and they’re not implementing the same functionality.

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.

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.

(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.)

All this was a problem under X. It’s still a problem under Wayland. It’s not a problem under Windows with WinCompose: it 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.)

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 do 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.

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.

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.

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.

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.

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.

If what is claimed here is true (wayland is a bad protocol) that might help explain the slow development.

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.

(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.)