> Re global hotkeys: I still don't understand your complaint. You just described two applications that didn't work and then went on to explain how one of them was made to work on Wayland. Yes, applications need to be ported, no solution on the Wayland side will ever change that. If the complaint is that the chosen method adds latency, or that the config setting has moved, those are vastly different than your original complaint which is that it doesn't work. Is that closer to what you were getting at?
Let's compare the workflows.
In X, in order to make guake open by pressing "F12" on the keyboard (which, by the way, is probably the feature that makes guake useful, since its entire purpose is to be a terminal you can pop up with a hotkey), I have to take the following steps:
1. Install Guake
2. Run Guake
That's it (F12 is the default hotkey for guake). It just works.
And it's the kind of thing that's possible on literally every other desktop OS that's ever existed prior to Wayland coming along.
Here's the steps I have to take when using mutter specifically.
1. Install Guake.
2. Realize F12 doesn't work because, in the Wayland ecosystem today, it is impossible for an application to bind a global hotkey.
3. Find a workaround online. Discover "guake-toggle" exists and that I have to manually bind a hotkey to call it.
4. Open the Gnome hotkey configuration screen.
5. Add a new binding for F12. Enter "/usr/bin/guake-toggle" as the command to execute when the key is pressed.
(actually, that's a lie, my vague recollection is you can't actually bind F12 at all in Gnome and so I used F11 as my test... but that's a whole other thing and probably a Gnome bug)
However:
1. This set of steps only works with mutter. For another wayland compositor the steps may be completely different. Or there may be no steps at all if the compositor doesn't have some mechanism to specify a global hotkey.
2. It happens to work with Guake because the author realized a wayland compositor was gonna need a workaround, and they created guake-toggle. For other applications it's possible no such workaround exists at all.
3. It's in any case a profound UX regression.
Now, yes, you can make the claim that guake was "made to work on Wayland".
But if your claim is that therefore nothing is wrong in this situation, I have to admit to simple astonishment and bafflement because I don't know how anyone could not see a problem here.
Now, to be clear: I'm not suggesting this is the sole issue that's preventing my use of Wayland. There is, after all, this crappy workaround.
Rather, as a reminder, this thread started with my replying to this remark:
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way.
I hope you can see that my issue isn't that I expect Wayland to "do all the same things as X in exactly the same way".
Rather, I expect Wayland to enable applications to offer the same kind of basic functionality, with the same level of usability, that users are used to experiencing with applications, not just on X, but on any modern desktop operating system.
This is just one example where that's actually not possible today due to immaturity in the ecosystem.
> Now, all that said, if you've tried recently and it's still not there, I absolutely get it.
Unfortunately I tried it... I'd estimate two months ago (I switched back to Debian testing from Ubuntu a couple of months back and decided to give Wayland a shot now that it's the default).
> You seem to be unable to have a good faith conversation about the merits of Wayland.
Actually, we haven't talked about the merits, yet!
Unfortunately, when I was playing around with Wayland, I struggled a bit to find the benefits that would make it so irresistible that I'd put up with the downsides.
Tear-free? Eh, I have that with X thanks to Intel's drivers. Though I absolutely understand that's not a universal experience.
Different display DPIs? Anything that falls back to Xwayland (which unfortunately is still a lot of applications) look like blurry garbage for obvious reasons, which means it's actually unusable in a lot of circumstances. And that's assuming solid application-level support (I seem to recall Firefox had mixed DPI regressions that were recently resolved, but that's only a vague recollection).
TBH, I was really really rooting for this feature as it could be really nice, and I was deeply disappointed when it didn't work out.
Touchpad gestures? Okay, legit these are really nice! Three-finger workspace switching in Gnome is pretty slick. OTOH, the lack of that feature isn't a dealbreaker, either.
General touchpad improvements? Funny thing is, libinput is being backported into Xorg, which means that you can get a lot of those benefits without switching. For example, I'm using Firefox with libinput2 and it's a fantastic improvement!
Honestly, I'd love a killer feature that'd push me to Wayland and cause me to put up with all the functional regressions. But I simply haven't found one... :(
So, at this point, I'm waiting for the regressions to be resolved. Hopefully we'll get global hotkeys, broadly supported screencasting, better application-level support for things like mixed DPI, and lots of bug fixes so I can finally make the switch!
> Please tone down the rhetoric, I'm not blaming anybody.
I understand that's not your intention, but that's effectively what you're doing.
I'm a former developer who moved into product management a long time ago, and I've seen the syndrome.
"I understand what you want, but we didn't build it that way, so you need to change your expectations" places the onus on the user to change their behaviour, instead of on the developer to build the thing the user actually wants.
> X is still included on those distros as a fallback option in case you have something that doesn't work.
The trouble is, a neophyte will a) have no idea what the difference is between Wayland and Xorg, and b) not realize that switching might fix whatever issue they're encountering.
And BTW, this all presumes that a distro installs Xorg at all. If not, you've gotta dive into the package manager, which adds an additional barrier since you need to know what to look for and install.
> Re global hotkey bindings: Can you please describe your setup to me? I honestly have no idea what you're talking about, global hotkeys were supported in all the Wayland implementations I tried recently. (KDE, GNOME, Sway, Wayfire)
It certainly doesn't.
Two examples that immediately spring to mind:
Guake, a handy pop-up terminal. In X I can press F12 anywhere and it opens. Super handy for quick terminal interactions, always-on commandline tools, etc.
Gnome Do or equivalent. Basically Quicksilver for Linux. Fast search, command execution, etc, from the keyboard. Hit a hotkey and it pops up.
Right now the way this works is that the compositor binds the key and then... does stuff. But that requires these applications to be redesigned to support that. For example, guake added a whole separate binary, 'guake-toggle', and it's only job is to toggle visibility.
Unfortunately, that requires the user to know that they need to go into their compositor settings, bind the key, and set it to run that application.
Meanwhile, on literally any other OS, this would be handled with a config setting right in the application.
Maybe eventually be addressed with yet-another-dbus-protocol, but right now it's just a gaping functional regression.
> My opinion - today - is that X doesn't work on laptops where the user expects to use a touchpad. Nor does it work on a laptop with a resolution that requires scaling (at least not the second you plug in another display).
None of those issues actually make X unusable. And I say that while writing this on an X1 Carbon running Debian testing using X in a multi-monitor setup (and yes, this is a totally plug-and-play setup with zero monkeying around in config files... a fact that, frankly, amazes me, having grown up hacking X modelines).
Wayland, by contrast, is literally unusable (as in, it lacks fundamental features that make it something people can't use) in many circumstances due to either compositor bugs, features that don't work by design, or features that don't work due to a lack of solutions or a lack of adoption of those solutions.
And I know this because I've tried to use it. I really like the possibilities it opens up.
But it's so far from mature, at this point, that it simply cannot act as an X replacement for most people.
Frankly, I'm a little shocked distros are making Wayland their default display server ecosystem, as it's an objective step backward for desktop Linux and I expect will scare a lot of neophytes away who wonder why the hell basic features like screensharing still don't yet work in their favourite application.
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way. It's not, that's the entire point.
Ahh, classic: blame the user.
You are wrong for expecting things to work in a way that's familiar!
Global hotkey bindings? Sure, that works on Windows, macOS, and X, but it doesn't on Wayland and its your fault for expecting it.
The beatings will continue until morale improves!
> As an end-user you can continue to use what works for you.
LOL, Wayland is literally being marketed as the replacement for X. It's even the default display server in Debian, Ubuntu, and (I think?) Fedora.
Why are you surprised that people therefore expect stuff that works in X to work in Wayland?
> You're here complaining that a maintainer isn't around to add features in a thread that's literally a major maintainer of X server telling you he's not going to work to maintain the project anymore.
I... think you already understand why this is a disingenuous argument, but I'll explain anyway:
The difference is, for most folks, X works, right now, today, while its maintainership is in question. For example, of the four items you listed, none of them particularly matter to me.
ydotool, as an example, doesn't work and it's not maintained.
Does that make sense?
> I believe Wayland can eventually replace the tools you need
Alright, well, ten years from now we should revisit this conversation!
Unfortunately, at this point, the Wayland ecosystem is looking a bit like Zeno's Paradox...
Because Wayland pushes so much logic into the compositor, there's now the very real likelihood that things will work on Gnome but not KDE, or work in i3 but not Gnome.
Case in point: Gnome + Wayland + guake. If you configure guake to use anything less than 100% of the width of the screen, then it suddenly appears in the wrong position.
But wait, maybe that's a guake bug, right?
Wrong. I tried a couple of other options for similar functionality and they demonstrated the same issue. So odds are it's actually a bug in the compositor.
And that's ignoring that basic things like global keybinding don't work (edit: ya ya, the Wayland proponents will tell you that's by design, but it's a) user hateful b) totally different than literally any other desktop OS out there today, and c) breaks apps, right now, in ways that will require major code changes to fix) so I have to put a hack in place to allow F12 to open guake up in the first place.
Meanwhile, we only just got the "official" solution for screensharing (what Zoom does is an incredible hack: they just take lots of screenshots! No, I'm not kidding, that's actually how it works, which is why the framerate is so bad) and it involves yet more new stuff (pipewire, et al) that I'm sure will be a source of its own raft of bugs.
I'd say "maybe in a year or two", but we've been saying that for a long time, now...
Let's compare the workflows.
In X, in order to make guake open by pressing "F12" on the keyboard (which, by the way, is probably the feature that makes guake useful, since its entire purpose is to be a terminal you can pop up with a hotkey), I have to take the following steps:
1. Install Guake
2. Run Guake
That's it (F12 is the default hotkey for guake). It just works.
And it's the kind of thing that's possible on literally every other desktop OS that's ever existed prior to Wayland coming along.
Here's the steps I have to take when using mutter specifically.
1. Install Guake.
2. Realize F12 doesn't work because, in the Wayland ecosystem today, it is impossible for an application to bind a global hotkey.
3. Find a workaround online. Discover "guake-toggle" exists and that I have to manually bind a hotkey to call it.
4. Open the Gnome hotkey configuration screen.
5. Add a new binding for F12. Enter "/usr/bin/guake-toggle" as the command to execute when the key is pressed.
(actually, that's a lie, my vague recollection is you can't actually bind F12 at all in Gnome and so I used F11 as my test... but that's a whole other thing and probably a Gnome bug)
However:
1. This set of steps only works with mutter. For another wayland compositor the steps may be completely different. Or there may be no steps at all if the compositor doesn't have some mechanism to specify a global hotkey.
2. It happens to work with Guake because the author realized a wayland compositor was gonna need a workaround, and they created guake-toggle. For other applications it's possible no such workaround exists at all.
3. It's in any case a profound UX regression.
Now, yes, you can make the claim that guake was "made to work on Wayland".
But if your claim is that therefore nothing is wrong in this situation, I have to admit to simple astonishment and bafflement because I don't know how anyone could not see a problem here.
Now, to be clear: I'm not suggesting this is the sole issue that's preventing my use of Wayland. There is, after all, this crappy workaround.
Rather, as a reminder, this thread started with my replying to this remark:
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way.
I hope you can see that my issue isn't that I expect Wayland to "do all the same things as X in exactly the same way".
Rather, I expect Wayland to enable applications to offer the same kind of basic functionality, with the same level of usability, that users are used to experiencing with applications, not just on X, but on any modern desktop operating system.
This is just one example where that's actually not possible today due to immaturity in the ecosystem.