The gnome X11 session no longer exists. See the release notes. What problems do you have on wayland?
Your other option is switching to a different DE, but plasma has also announced that X11 will no longer be supported quite soon. It’s time to figure out any remaining issues you have; wayland should be unproblematic at this point.
Explore your options to replace those workflows, as it will only get worse and not better with time. Xserver is dying off slowly as major projects like KDE and Gnome deprecate it. You will have to migrate to an X-based DE/WM explicitly, like XFCE if you want to stay X. Other options include changing the apps. Foot terminal does literally what you’re describing by default and is very popular.
Reverting is the worst possible choice on the list.
There are many alternatives to these things that will work out of the box on wayland.
Flameshot in particular does support wayland these days anyway, so that should be zero effort to fix: Wayland Help | Flameshot
As for copyq, there are lots of other clipboard managers. And for the last item in the list, just replace wmctrl with a wayland-native command; there are protocols designed for exactly this use case. wmctrl is explicitly designed for X11, of course that doesn’t work on wayland.
I don’t think sticking to an insecure OS over just trying some alternatives for three applications is reasonable at all. As a temporary measure, perhaps for a few weeks, sure, but the writing’s on the wall; eventually you will have to migrate.
You can switch to xfce or such, but those desktops will become less well supported over time. No reason to be stuck in the past if you really just have three relatively small issues.
Interesting to see xfce mentioned thrice as even they have started wayland development as of last year: releng:wayland_roadmap [Xfce Wiki]
Also to add, do not start randomly adding portals to your config, as that will not work - that page is primarily for non-NixOS users. If you can describe your problem in more detail than “can not capture” then we can actually try to help here.
Yeah, sorry, I should be more clear. Most likely getting flameshot to run under wayland is as simple as replacing your current keybinding with the ones suggested on that page, i.e.:
QT_QPA_PLATFORM=wayland flameshot gui
It’s a QT application, and sometimes those need to be forcibly coaxed into using the wayland backend, but nonetheless, QT supports wayland.
Anyway, the issues aren’t with wayland, but the fact that application developers still refuse to target it primarily. This will change as X11 desktops go the way of the dodo, and it will happen more rapidly than you think now gnome/kde have both jumped ship.
I expect it to take one or two ubuntu LTS releases to completely disappear, and likely one or two normal ubuntu releases for most of the FOSS world to catch up.
The fact that for many things there is no single «Wayland» to target, because there is still not unified version of the protocol designed differently by different implementations (and each DE needing a different implementation of that part is new with Wayland compared to X11) is absolutely a problem with Wayland, though.
Window management & such is identical between all of them.
It gets less unified when details like GNOME shell or the wlroots “layer shell” are involved, but that pretty much only applies to stuff like docks, which are naturally quite desktop-specific.
The big exception is “auto-type”, screenshots and screensharing, since upstream takes the position that these things need security attention and therefore need UI, which is desktop-specific. You may disagree with that opinion, but specific exclusions like this are far from:
The anti-wayland thing feels very similar to the anti-systemd thing to me, people just complaining about change because they don’t understand it and go off hearsay from the internet. There are things to critique, but this ain’t it.
«Takes security seriously» that does not include identifying the source of remote control request.
And speaking of «needs UI», window placement in X11 is done in a way where some WMs apply preconfigured policies and some WMs implement a UI for the user to make a case-by-case decision. Somehow, it works with a single standard protocol both application-side and WM-side.
Anyway, if Wayland as a protocol is in a good shape now, surely they have gotten around to standartising the application side of screensharing requests?
Also Xorg has standard XRandR and XInput configuration, meaning you can query and control things according to where your laptop is, independently of what a DE forgot to think about.
Well, obviously Wayland is formally speaking better than systemd because systemd caused any systems using it to gain new outright breakages w.r.t. Single Unix Standard, and X11 does not have a separate full-out standard.
There you go, now you’re critiquing details instead of spreading falsehoods. Well, partially, you clearly didn’t read the protocols.
I’m not particularly interested in discussing the minute details of each protocol; there is a lot about X11 that can be criticized as well. That discussion is entirely unrelated to this thread, and I don’t have a horse in the race.
It’s also entirely besides my point; regardless of your opinion of the choices the wayland protocol makes, most DE/WM upstreams clearly see its benefits and have made the choice for you, just like most distros have made the choice w.r.t. systemd.
«Most DE upstreams» are not really forcing the choice (at least not for people using WMs that are actually stable and not on a fast treadmill); putting applications in some kind of Xorg-backed Wayland miniinstances still gets me XRandR and XInput and scripted control benefits; the question is mostly when driver situation makes running Xorg on fresh kernel untenable.
What I was saying was not false, and also about design decisions that are higher-level decisions than what you can read in the protocol definition.
