Most of the GTK environments seem to be doing fine. Most of them seem headed to Wayland as well with the maturity of GTK in Wayland making that easier. Cinnamon will be ready for Wayland in a few months with both XFCE and MATE likely to have something out next year.
Incredibly, GIMP itself may finally get off GTK+ 2. They claim that GIMP 3 will launch in February. We will see how long it takes to get to GTK4. I think the transition will be easier. The jump from 2 to 3 was a big one.
COSMIC of course is going its own way with the Iced toolkit.
On the app side, GTK seems to still be a very popular option.
In terms of conclusions, I do not see mainstream resistance to new GTK versions. Some people balked at GNOME 3 but GNOME today seems more popular than ever. MATE faithfully kept the old GNOME experience but has migrated to newer GTK. It was not a rebellion against the toolkit.
A great middle-ground is EndeavourOS. It has a great installer. It makes pretty decent choices. You have a pretty much 100% pure Arch system after install. There are only a couple dozen EndeavourOS packages and most of them are utilities. You can remove all the EndeavourOS stuff in a couple of minutes if you really want to and comment out the repos. Not sure why you would. Just pointing out how vanilla it is.
Are you saying that as an Arch user or a Manjaro user? Have you ever used a different Arch distro? I am just wondering how many of the “other Arch distros are just as broken” people have actually used both. I have used several. In my experience, Manjaro stands alone in terms of the number of problems I have had. I guess I am just unlucky.
I am not theorizing. And I am not taking about source code not compiling. I am talking about dependencies which includes the reports version numbers and version number expectations of packages maintained by different parties. Those broke all the time for me on Manjaro and it was often because of the differences between what was in the Arch repos vs the Manjaro repos.
When Manjaro fell behind at one point, I ended up with a version of GEGL ( labeled - git ) being pulled from the AUR. Later releases of GIMP refused to upgrade over that version of GEGL. I just lived with it for a few months hoping it would clear itself up but it never did. I basically had to back everything my out and install again. Not that it was hard but these kinds of annoyances happened for me all the time on Mnajaro and basically never on EbdeavourOS or Arch.
What made me move away from Manjaro to begin with were all the problems it had with the dotnet packages at the time. I blamed dotnet and the AUR and was amazed that the problems went away when I used EndeavourOS instead.
People are completely missing the point here. “Who made Red Hat the arbiter of when Xorg should end?”
I would say nobody but perhaps a better answer is all of us that have left the work of maintaining Xorg to Red Hat. All that Red Hat is deciding is when they are going to stop contributing. So little is done by others that, if Red Hat stops, Xorg is effectively done.
Others are of course free to step up. In fact, it may not be much work. Red Hat will still be doing most of the work as they will still be supporting Xwayland ( mostly the same code as Xorg ), libdrm, libinput, KMS, and other stuff that both Xorg and Wayland share. They just won’t be bundling it up, testing it, and releasing it as Xorg anymore.
There are many cases where Manjaro causes problems. For example, a package mag already be in Arch but not yet in Manjaro. Or perhaps the Manjaro package is not a high enough version number. If another Arch package requires this first package, in Arch it would grab the Arch package. The Arch package will be maintained over time. In Manajaro, the package is not there and so the AUR grabs it from the AUR as well. Perhaps it is even the Git version with an unclear version number. Over time, the AUR dependency breaks or becomes unmaintained. Even once Manjaro has the package, it may not migrate it because of the version numbers. Now things are broken. This exact thing happened to me on Manjaro where my GIMP ended up using GEGL from the AUR. My system was broken for months.
An even worse problem can happen when there are alternate dependencies. Sometimes in the AUR you will have multiple packages that fulfill a dependency. In Arch, you can see if one is from the actual repos and one is itself from the AUR. Again, if you choose the one in the repos, it will work and stay supports. In Manjaro, neither may be coming from the actual repos in which case it is easy to choose the wrong one. This sets you up to have package conflicts. In Manjaro, I would never know that the other option had now been added to the repos. More than once, I had the dependency that I had chosen break when the other would still have been fine.
Ok, this is getting long and that was just a couple of scenarios.
Suffice it to say, when I used Manjaro, I got the impression that the AUR broke all the time and that using the AUR broke my install from time to time. Now that I use Arch, I do not have those issues and I realize that it was Manjaro all along.
I used to be a huge Manjaro fan. There were many ways it let me down, some of which were just bad governance.
The biggest problem though is the AUR. Manjaro uses packages that are older than Arch. The AUR assumes the Arch packages. This, if your use the AUR with Manjaro, your system will break.
It is not a question of if Manjaro will break but when. Every ex-Manjaro user has the same story.
For me, EndeavourOS is everything that Manjaro should be.
My experience with Arch is that it has been very solid and stable. It is just “makes sense” for the most part and so issues are very resolvable.
If you use the AUR, you can get times when packages need to be excluded ( held back ) in order for the overall system to update. I do not see that as an Arch problem and it is easy to handle.
One thing that is an Arch problem is that, if you do not update often enough, you can end-up with outdated keys that prevent you from installing before packages. The solution is just to update the keyring before updating everything else but this is confusing for a new user and kind of dumb in my opinion. I feel like the system should do this for me.
Ironically, I find Arch is most stable if you update very frequently ( which makes the updates smaller and more incremental ). I do a quick update almost every day without any fear of breaking my system. Any “problems” I have had with Arch updates are trying to update a system that has not been updated forever. Even then, it is just a bit more work.
Another thing that can happen if you leave it too long is that packages will have been replaced by newer ones. Keeping up to date means there are only going to be a small number of those. An update after a year can run into a surprising number of them.
I dug out an old laptop that had Arch on it from 3 years before. Updating it was annoying but in the end it was totally up to date and stable.
Xwayland is likely to be with us a very long time. I do not see Motif adding Wayland support anytime soon for example. How long for GNUstep to hop on board?
I am usually on the pro-Wayland side but with GNOME and KDE the Wayland implementations are fairly independent. That means that your statement that KDE going “Wayland by default is going to benefit gnome too since it’ll put more priority on bugs” is watered down somewhat.
Fixing bugs in the KDE compositor / display server ( KWin ) will not necessarily address bugs or missing functionality in GNOME ( Mutter ). A lot of what they share is also shared with Xorg ( libinput, libdrm, KMS, Mesa ).
On the application side, apps lean heavily on the toolkit libraries. KDE apps are built with Qt and GNOME apps are built with GTK. Fixing Qt bugs may not improve the quality of GTK and vice versa.
Smaller projects will share more infrastructure. Many other environments are using Wlroots as a compositor library for example. Fixing bugs there will benefit them all but again is independent of KDE and GNOME.
Your point is still valid though. For one thing, the larger the Wayland user base, the greater the number of use cases the Wayland protocol itself will be adapted to address and the more testing and development everything in the Wayland ecosystem will get.
Over time, one benefit of multiple implementations will probably be code quality. Apps that run well in multiple environments are well implemented and the same is true of environments that provide the necessarily features to a large body of apps. In that way, more bugs will be found and fixed in all environments.