Somehow my windows taskbar crashes... And alt tabbing doesn't work properly, I have to manually click on the windows in the overlay. My taskbar is always on top of windows, and they don't respect it's space so they just go under it and hide important stuff. Except firefox, which does respect the taskbar's space on a non-primary monitor, obviously leaving the space, but on the main screen it overlaps the taskbar entirely.

>If I could stay on X11 for a decade from now on

I think they all talk about that move but i make a bet no one will actually do it. Remember Nvidia?

And i think anything archlinux/gentoo will stay with x11 AND Wayland for at least the next 10 years.

> no one will actually do it. Remember Nvidia?

It's surprisingly usable these days. GSync/VRR has a bit of a frame order problem but the desktop feels really zippy.

It's just snagging at this point. They fix a few more bugs, improve nvidia-settings, maybe sprinkle on some HDR and that's a lot of complaints ameliorated, at least until we all move to Yutani, or whatever the next graphics server's called.

> I think they all talk about that move but i make a bet no one will actually do it.

RHEL 10 is going to be Wayland only. You will be able to run X11 apps via Xwayland, but not full-blown Xorg server and X11-only session.

Yes things that were broken for me by default are explorer, notepad (using it with files over a network), calendar pop up, and start menu. And don't get me started on the UI of the sound/battery/network widget.

Every day I'm reminded of something I think Jo Armstrong said in a talk, paraphrased "Ah, an update! Maybe they made it better ;)".

To paraphrase Foone

"The year on the Linux desktop won't be because Linux got better"

i think there is something wrong with your machine, probably malware of some sort, or whatever this "gesture" stuff is doing. clean install probably indicated.

You'd feel at home at answers.microsoft.com as one of their expert "Independent Advisors".

No malware. Clean install is not an option.

if you are considering switching to linux, presumably a clean install actually is an option.

There's absolutely no way your computer is functioning properly if you have multi-second delays on a simple double-click in Explorer.

I think you need to ditch the tape storage system then and maybe move to something from this century

i agree, however windows does have a way of locking you in to explorer with no practically viable alternative

Explorer seems to have always been plagued by some original sin around how it's event model works. Blocking the main thread until every app involved can feed back which can often require network lookups. You can see them trying to move to an intent system but there's too much legacy for them to move past.

RHEL 9 should give you a guranteed X11 experience until 2032 at least.

If you wanted, you honestly could stay on X11 for the next decade. I highly doubt it's going anywhere. Also, no matter what your workflow is, you can write a program to do that. I'd guarantee you could write a small script to automate Wayland to do what you need

Right about now KDE is moving to Wayland. KDE Plasma 6 released a week ago will use Wayland by default, with X11 being an opt in mode. I think that X11 while it might exist for the next decade, it will at best be a second class citizen, at worst a buggy and unsupported mess

And even if they pull X support, do you have to use Plasma 6, 7 or 8 in the next decade?

Sometimes it's okay to use old software, especially if it works well for you.

Is it technically possible to guarantee program-agnostic mouse gesture support in Wayland? I would sorta expect wlroots to support it, but I don't think that is a safe bet for an arbitrary Wayland compositor.

This is my main issue, I need full access to input devices and the ability to drop, alter and inject new events.

On Windows I fully rely on StrokeIt, it has been a huge improvement for me which I've used for ~15 years.

Linux's easystroke [0] is now deprecated (and always was mediocre) and the modern alternative "mouse-actions" [1] is not good at all.

I've coded a replacement in Rust+C which works for my simple use-case but it targets X11 and it's unclear for me how I can get low level access to input devices events with Wayland. I've also read something about security getting increased in Wayland so that one does no longer have access to input stuff (unclear to me).

Then the nice thing about X11 is the ability to remotely use a X11 session, which apparently isn't possible with Wayland (except for RDP or VNC which isn't what I need).

[0] https://github.com/thjaeger/easystroke/wiki

[1] https://github.com/jersou/mouse-actions

> ... and it's unclear for me how I can get low level access to input devices events with Wayland.

You can't as far as I know, the reason it has taken more than a decade to gain adoption is the protocol design turned out to be unusable for desktops (at least, probably other platforms too). I've been avoiding it because Zoom & friends didn't work when I tested them. My understanding of the de-facto situation is that everything sucked for about a decade from the release, then (special mention to Drew DeVault) people started extending the Wayland protocol to cover the original design mistakes.

Documentation is available [0]. If I were trying to understand the state of play for mouse gestures I'd probably start by researching what is going on the wlroots project, that seems to be where a lot of the useful innovation was coming from. The extensions implemented in the compositor look like they matter a lot.

[0] https://wayland.app/protocols/

Zoom and friends didn't work, because they thought they can grab root window content and run with it. By a chance it did work in X11 due to how PC hardware worked and thus Xorg organized it's framebuffer, but doesn't neither Wayland (for obvious reason), nor when hardware uses it's newer features, like overlays. Even on other platforms, they have to ask, and the user might permit that. They just didn't bother to ask on Linux (it is done via pipewire), and didn't bother to fix their approach.

But that gets back to the basic issue here - the answer to "how should Zoom take screenshots if someone is using a Wayland compositor?" turns out to be "Well, you needed to implement a separate server that re-imagines video as streams, like PulseAudio. Then they have to interface with that. Of course, Wayland doesn't support that (it explicitly makes it hard, in fact), so someone needs to design a protocol extension [0] first to make all this work".

That is a very complex answer. On X, the answer is "grab the relevant window". I can see why Zoom gave the whole mess a pass until the community sort themselves out. I'm doing the same thing; although it looks like (checks) 15 years of patience has been rewarded and Wayland isn't too much of a backslide from X servers.

Unfortunately automating I/O still isn't all that clear, I'd have clicking automated before I move over; it probably is possible but it is just a messy situation to figure out how.

[0] Technically not a Wayland extension, they bypassed the entire system. So now "Wayland compositor" tells us nothing whatsoever about whether the system can take screenshots, but we have to look up compositor-specific support for screencapture. The situation is ... technically better than X, but still silly. They could have avoided years of wasted time by just acknowledging that people want to intercept data as part of the protocol. The situation is a mess and it is silly that we can't have generic Wayland screenshot applications.

The thing is, just grabbing the root window didn't work for 100% either. Outside of the permission problem, there were others: at first, people noticed, that the mouse cursor is missing, so the screen grabbing apps had to handle that as an extra (get the cursor shape, it's position, superimpose it on the from previous step pixmap). Then, if you happened to use Xv, the content was missing too, you got the chroma key used instead. This use case was never handled while Xv was used, the problem was solved when it became obsolete.

The point is, you either implemented a quite complex way to get a screenshot, or just used another implementation as a library. For a screencast, you discover a new here-are-lions land, since you are going to read out VRAM for each frame, with corresponding "speed" and CPU load.

So yes, separate server handles that and more for you. Compositors finally can use overlays (that's how they emulate different scales or resolutions for clients like games, while using native resolution of the display). Pipewire/gstreamer implement a hardware accelerated, zero copy screencasting for you, so you don't have to do it yourself, just call the right portal.

Yes, apps have to change. But they already do change, at least on other platforms. Apple does way more changes in their system, and do you see anyone waiting for several releases until they update? They changed their arch for christ's sake, and except for the long tail, everyone updated within few months. Why it is so difficult on the linux side?

Maybe the reason is not that it is difficult to update, but that the linux users accept crap and apple users don't. Do not accept crap by the proprietary vendors, and they will step up their effort. It's that simple.

> I've been avoiding it because Zoom & friends didn't work when I tested them.

If you are talking about screen sharing Zoom, Meet and Slack work fine on Debian stable running Wayland in KDE and Gnome. Teams probably doesn't work on Wayland, but then Teams working on any other platform on a given day is at best a lottery.

There's no native Teams for Linux anymore, only the browser version. Browsers have no issue working with Wayland/pipewire.

> If I could stay on X11 for a decade from now on

why is that?

I am asking, because so far I have seen old linux users refusing to move because they require some specific x11 feature that is not (yet) supported on wayland. I thought that new linux user wouldn't have such requirements.

Personally for me such migration-blocking X11 feature is "not crashing".

A way this used to be possible, also before win11, was misbehaving custom extensions to the explorer shell. IE, some applications install extra menus and handlers as part of the windows shell. Particularly, some such extensions may fight with each other - you can have one installed, or the other, but not both. I use the tortoiseGIT extension to integrate git into explorer, and a lot of the bugs it has seen over the years, have really been work-arounds to survive OTHER broken explorer extensions. My point being, the problem may come from one of your staple applications, not from the fresh window install(?).

I have several tools installed, also such which hook into explorer, but not more than I had with Windows 7, which I replaced last year with Windows 11 on a much more modern machine.

Two weeks ago I had to boot into the Windows 7 on the old machine (it now boots into Linux by default and I use it occasionally) and almost tears came to my eyes when I saw how fast that 13 year old machine is.

Windows 7 was pretty good as an OS.

What exactly is your problem with Wayland? It works fine.