xdg-desktop-portal is a workaround for the chaos Wayland caused. It puts the implementation burden on all of the individual "compositors" (read desktop environments) individually, resulting in many times the work, many incomplete and many incompatible implementations.
The Wayland devs hyped their project up like it's going to be the thing to replace X11, but ended up delivering barely 10% of what X11 is.
One of the beautiful things about Linux was that you had thing huge variety of desktop environments and the reason for it was that X11 gave you all the infrastructure, you only had to do the user-facing parts. Now, a DE needs to implement all of X11 and then some to be feature-complete.
And no, I'm not accidentally mixing up DEs and compositors - the reality is that we don't have a good "base compositor" that DEs could build on top of. The big players built their own compositors and the small players either died or used wlroots, which again doesn't implement most of the essential things (and the ones it does are incompatible with KDE and GNOME).
>One of the beautiful things about Linux was that you had thing huge variety of desktop environments and the reason for it was that X11 gave you all the infrastructure, you only had to do the user-facing parts.
Why do people like to emphasize this point so much? You still get shared infrastructure in the Wayland ecosystem by utilizing libraries such as wlroots or Smithay.
In fact, GNOME and KDE are practically the _outliers_ of the ecosystem as they do their own thing, but other compositors such as Hyprland or Sway do share the same core.
If you want even higher level of abstraction so that you can make your own window manager in one hundred lines of code, you can opt to write a Wayfire plugin. It's as close to having a "base compositor" as possible.
GNOME and KDE definitely are the outliers, but they are the biggest players and they didn't do this out of sheer evil or whatever. They did this because when everyone was pushing for Wayland adoption, wlroots didn't exist or wasn't usable. And when it came out, everyone called it a "reference implementation" and it was expected of DEs to implement their own compositors.
And the main problem wasn't even that DEs didn't have a shared codebase for compositors, it was that there weren't any standards for critical features of any modern system. It was all "up to the compositors", meaning it wasn't just a matter of implementing some APIs, they had to be designed first. We now have different protocol extensions for KDE and wlroots alongside external DBus-based APIs for GNOME that have now also been partially implemented by KDE, yet there are still basic X11 features that can't be done on all of these compositors.
> And when it came out, everyone called it a "reference implementation" and it was expected of DEs to implement their own compositors.
Small correction, it is Weston that was a reference implementation. Weston was developed alongside the standard, so it's always been around. Whereas wlroots is very much supposed to be a practical implementation, but only came later.
The Wayland devs hyped their project up like it's going to be the thing to replace X11, but ended up delivering barely 10% of what X11 is.
One of the beautiful things about Linux was that you had thing huge variety of desktop environments and the reason for it was that X11 gave you all the infrastructure, you only had to do the user-facing parts. Now, a DE needs to implement all of X11 and then some to be feature-complete.
And no, I'm not accidentally mixing up DEs and compositors - the reality is that we don't have a good "base compositor" that DEs could build on top of. The big players built their own compositors and the small players either died or used wlroots, which again doesn't implement most of the essential things (and the ones it does are incompatible with KDE and GNOME).