I'm overall happy about this. (I went to post the GNOME foundation post about it, but it was already dead in new when I looked.) It's good to see support for op

I'm overall happy about this. (I went to post the GNOME foundation post about it, but it was already dead in new when I looked.) It's good to see support for open source projects and developers. That said, unfortunately, I echo the statements from others: I think they really ought to have picked KDE. I think KDE better embodies the spirit of the Linux desktop and open source, even for all of its flaws, of which there are many. I'm sure GNOME has a lot of avid fans and users, and having used Phosh I'm legitimately impressed at how good GTK4 and libadw have gotten for mobile. That said, I still feel like it makes a pretty bad productivity desktop, and there's a reason why every alternative GNOME or GTK-based desktop from System76 Cosmic to Budgie to XFCE is either ditching or ignoring Mutter: GNOME's fumbling of the Wayland bag has been painful for the whole ecosystem. I hate to complain about anything that is literally free, but it has become a genuine depressing drain. We could've just had pragmatic SSD support in Mutter, but instead all we have is libdecor, an option that is not ideal (especially for apps not written in C) and seems like it's perpetually not ready. Sometimes it feels like your actual best option for getting window borders in GNOME might be sub-surfacing yourself into a GTK4 window. And it's even more frustrating, because some of the developers are great. I am a huge fan of libinput in general. I was looking forward, then, to checking out libei, a library (in theory) that lets you emulate input, e.g. to inject events. A library like libei could be great, because there's already a lot of Wayland compositors (most Wayland compositors) that support input injection today, so making it into a C library seems smart. Unfortunately, libei doesn't support them. Apparently, it is not "waylandy" (??????) to put input injection protocols in Wayland, and libei is only designed to support its own homegrown RPC solution which is a slightly modified version of the Wayland protocol instead. The way libei is supposed to work is that you use it, and it connects over a socket to the eis server, which speaks the ei protocol. How do you know which eis server to connect to? From the libei side, there's no prescription here. But it's OK. Mutter doesn't expose an eis server directly. Apparently, you need to go through XDG Desktop Portals to use libei on Mutter. Because this is insanely convoluted, the foresight was had to develop liboeffis, a library that does XDG Desktop Portal interactions for you so you can get a socket to the eis server without having to care about all of that dbus crap. I tried compiling a version of GNOME that had eis support (at the time NixOS didn't have GNOME 45+, I don't know if it currently does) and I was either unsuccessful at that, or unsuccessful at getting libei to work. No matter how hard I tried, nothing really seemed to work right. Meanwhile, on wlroots compositors, you can just use the Wayland socket itself: https://wayland.app/protocols/virtual-keyboard-unstable-v1 https://wayland.app/protocols/virtual-keyboard-unstable-v1 https://wayland.app/protocols/wlr-virtual-pointer-unstable-v1 https://wayland.app/protocols/wlr-virtual-pointer-unstable-v... This, of course, makes a lot of sense when you consider that the input events you're injecting will... you know... go over the Wayland socket. It's a perfect way to speak to the correct compositor, since I already am speaking to the correct compositor. Why introduce another socket? Meanwhile, while lacking this rather basic feature, libei allows for backends that do things like use uinput, which to me makes no sense. The big difference between libei and something like uinput is that I'm injecting events on the compositor side. It's like the difference between telling the compositor to move the mouse to 4, 4 and generating USB HID motion events to do the same. Almost every other platform has a serviceable API here, and it's useful for accessibility, automation and testing, and probably more. Unfortunately the story today with Wayland is pretty mediocre and even more unfortunately the direction it seems to be going doesn't look like it will improve unless you're willing to only support wlroots. This sucks because I want to work on cool Linux desktop software, but in practice I'm so bummed out by the time I scale through the mess of a stack that has developed in the desktop side that I basically lose interest. And to be clear, I'm not saying the wlroots ecosystem is perfect. Like I don't think there's a good way to make a virtual graphics tablet device yet in wlroots, which would be quite useful for a project that I wanted to work on (trying to get support for Windows WMPOINTER_* events in Wine; making Winetests for this would probably ideally involve virtual input, but lacking even basic support for what XTEST does, it's hard to imagine making these tests work in Wine any time soon, and compositor-specific protocols are a no-go afaik.) It'd be nice to have something like autohotkey for Linux, too. But I think by the time a developer has gone through the realizations that I have, they are probably too drained to even think about working on it. (Despite all of this, I really am still glad for it, and I believe some day all of this crap will get sorted out. I guess a part of me types out these huge rants just to vent, but another part of me hopes someone who has influence to fix things will read them and realize the situation sucks. Wishful thinking.)