10 ms·
The reality of Wayland input methods in 2022 (2022)
- ChuckNorris89 3y ago"Conclusion 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. Thank you"
- Spivak 3y ago> users will ditch the Linux desktop Mhmm, this is what will push users from the Linux desktop. Not the billion other usability issues. I think this is a case of someone caring a whole heck of a lot about a small thing.
- Dalewyn 3y agoHis first error is daring to assume there are users who will ditch Linux desktop. His second error is daring to assume the Linux community cares about GUI. Until advice and tutorials stop beginning with "Open the terminal..." there is no such thing as Linux desktop.
- zdragnar 3y agoI know several who did. They get macs through work, and that was "good enough" that they stopped caring. Personally I hate the macos desktop and window management, and prefer Linux on a few others things, so I'll keep using it as long as I can.
- deleted 3y ago[deleted]
- hornban 3y ago> How can there be no books published on the subject of Wayland programming in 14 years? Just my personal observation here, but I don't see a lot of value in programming books any longer due to how often things change. Usually I'm looking for official documentation or recently updated blog posts on the Internet.
- speed_spread 3y agoThe difference being that X development has essentially _stopped_ because it's so complicated that nobody wants to touch it anymore. Does it work? Yes. Is it mature? Yes. Are apps more compatible with it? Yes. Will it evolve from there? No. While Wayland has been picking the slack slowly, it has been usable for years now and apart from the screen sharing issues and occasional driver problem. Wayland will continue to get better and make a graphics stack that's more adapted to modern needs.
- GauntletWizard 3y agoI'm one of the many users who will take a mature, well tested product over one that's experiencing "Ongoing Development" and lacks many of the features they need. Too much ink has already been shed around the faults of Wayland, but I'll put it pretty simply - The people on Wayland have no business designing user interfaces and are questionable at developer interfaces.
- kaba0 3y agoIf you mix up wayland with user interfaces, you are not even in the ballpark of getting the deal — pretty pretentious to have such a strong opinion on something you know jackshit about. Especially that the people on Wayland are literally the ex-maintainers of X.
- bandrami 3y agoThe OpenBSD team is still developing the Xenocara X11 system, though AFAIK they aren't particularly adding features because the system is feature-complete (they aren't adding features to relayd either but it's not "abandoned" in any sense: as much as it conflicts with the CADT philosophy it's actually fine for software to be mature). While I don't like making predictions, if I had to guess I'd guess that in a decade's time the OpenBSD team will be maintaining the upstream display server for most Linux distros just like they maintain the encrypted shell and the BGP server for them.
- sterwill 3y agoSo 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.
- Y_Y 3y ago[flagged]
- mzs 3y agoGuess you don't use cyrillic and extended latin.
- Spivak 3y agoAlso been using Wayland for years via GNOME, everything works, I have cool new dbus APIs to control my desktop, the "press ctrl+alt+f2" to bypass the lockscreen" thing isn't a thing anymore, libinput is leaps and bounds above everything that came before it.
- bandrami 3y ago> libinput is leaps and bounds above everything that came before it Oh Lord no. Clickpads are still basically unusable with libinput. There's a reason it hasn't actually displaced synaptics.
- talhah 3y agoI've also been using wayland for a couple years now. Switched from i3 to sway and never had screen tearing as I did with X server. Just recently moved to Hyprland and similar experience. Barely had any hiccups and switching to a non-english layout such as Arabic works like a charm. Perhaps maybe our systems are just ideal? For the record I'm using a thinkpad which generally has good support but even on my Lenovo G505 it worked perfectly.
- LoganDark 3y ago
- oriettaxx 3y agoI had to stop using Wayland: cannot share desktop with zoom or meet (it crashes)
- zdragnar 3y agoMeet shares my screen just fine. Zoom claims that it should, but it refuses to recognize my setup as "supported", probably because I'm using sway and not gnome. I got it working for awhile, but after an update it stopped. We mostly switched to meet, and I stopped caring. If I need to share my desktop in zoom, I just drop from the meeting and rejoin from chrome instead of the app.
- chrismorgan 3y agoZoom used to work in Wayland quite some time ago, then it started crashing on meeting join under Wayland, and it was still like that last time I tried it under 5.11.10. Then they finally implemented screen sharing properly in 5.10 or something, then in 5.12 they actively broke it again (popping up a message box saying it won’t work except under GNOME or something like that), so I downgraded to 5.11.10 and it’s fine again. I tried 5.13.0 and it was still broken. I haven’t tried upgrading since; maybe they’ve unbroken it again, one can always hope. Anyway: Zoom 5.11.10 is working fine for me in all regards so long as I run it under XWayland. My ~/bin/zoom: #!/bin/sh export WAYLAND_DISPLAY= exec /usr/bin/zoom "$@" I believe a shell alias would also work if that’s how you run things. Minor suboptimalities in its window management and UI scaling compared to native Wayland under Sway, but nothing big, except for it only handling input and screen updates around once a second if you have any window (except the main one for some reason—but settings, a meeting, chat, participants, they’re all affected) open but not visible (e.g. as an inactive tab—tiled or floating is fine). Oh, and that I get REPLACEMENT CHARACTER from typing astral plane characters with my Compose key, which strongly suggests stupid UTF-16 stuff and I can’t remember if that happens under native Wayland anyway. Or the hidden window problem.
- jchw 3y agoI 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. 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.
- kennethrc 3y ago> A vast majority of the Linux desktop ecosystem has been on NVIDIA graphics cards Source? Nvidia's proprietary, closed drivers and the moving target that comes with that means I avoid Nvidia graphics hardware at all costs and I'd thought it was widely known their cards aren't great if Linux is the primary use for your hardware. (Linux is my daily driver and I also develop on/with it, but I don't game at all)
- FloatArtifact 3y agoThe 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.
- jrm4 3y agoI'm going to ask this in every thread. 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?)
- benwaffle 3y agoHow exactly does GNOME make money by not building a "classically usable" desktop? What about Ubuntu?
- shrimp_emoji 3y agoThey benefit from their purer FOSS licensing behind GTK (in contrast to their competition, Qt) and place in history. They're working on a doomed experiment, on the fumes of enchantment of Apple design and the false hope that, maybe someday, "regular people" will use Linux. On a tablet or something. It'll all be tablets -- nobody'll even have desktops anymore. The hardware will converge, if you will. There will be a Unity of interfaces.
- Dalewyn 3y ago>maybe someday, "regular people" will use Linux. On a tablet or something. It'll all be tablets We already do, it's called Android.
- jrm4 3y agoCargo culting, kinda. They're trying to "innovate like Apple," and of course, it's not very easy to do that.
- chrismorgan 3y agoAnecdotes as a Sway user and formerly i3 user. 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.
- bandrami 3y ago> All this was a problem under X What is the problem under X? I set the compose:ralt xkboption for the server and the clients don't even have to know about it.
- bitwize 3y agoFor 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. (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.)
- bandrami 3y ago(Yet another reminder that Xenocara exists, is still being maintained, and runs on Linux, or at least did a year ago)
- i2cmaster 3y agoOpenBSD always seems to have the sanity you would normally expect from GNU/Linux. I already run their WM, I might switch entirely to their OS.
- bitwize 3y agoBut Mr. Anderson, what good is an X server... if no toolkits support it?
- bandrami 3y agoThis is the silliness I'm talking about. Nobody's going to go rip X support out of toolkits. Distros still ship token ring support; they're not going to literally "get rid of" X either.
- bitwize 3y ago> This is the silliness I'm talking about. Nobody's going to go rip X support out of toolkits. https://gitlab.gnome.org/GNOME/gtk/-/issues/5004 https://gitlab.gnome.org/GNOME/gtk/-/issues/5004
- jacknews 3y agoSo is there a project/protocol that everyone can get behind? 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.