> The problems you have with one of them might not appear in another.

Because both have their own portal implementation/compositor with their own issues and service spec implementations. KDE has xdg-desktop-portal-kde, and GNOME has xdg-desktop-portal-gnome. On top of that each (still) has their own display server; KDE has KWin, and GNOME has Mutter.

> The reference compositor, Weston, is not really usable as a daily driver.

Weston is probably good for two things: Running things in Kiosk mode and showcasing how to build a compositor.

That's why you should at least use xdg-desktop-portal if you are not running KDE or GNOME. But this is a vanilla compositor (without implementations of any freedesktop desktop protocols), and as-is has no knowledge of things like screenshots or screensharing.

If you run any wlroots based compositor except Hyprland you should run xdg-desktop-portal-wlr which does implement the desktop protocols org.freedesktop.impl.portal.Screenshot and org.freedesktop.impl.portal.ScreenCast.

If you use Hyprland you should run its fork xdg-desktop-portal-hyprland instead which additionaly has things like file picking built in. Additionally you can/should run xdg-desktop-portal-gtk and/or xdg-desktop-portal-kde to respectively get GTK ("GNOME") and QT ("KDE") specific implementations for desktop protocols. And you absolutely should use xdg-desktop-portal-gtk instead of xdg-desktop-portal-gnome, because xdg-desktop-portal-gnome really doesn't like to share with others.

> With Wayland the each desktop is reinventing the wheel

Not really true, as I mentioned earlier there's still a DE specific display server running in the background (like Mutter and KWin-X11 for X11), and graphics in each compositor is driven directly by the graphics driver in the kernel (through KMS/DRM).

In fact, on paper and in theory, the architecture looks really good: https://wayland.freedesktop.org/architecture.html. However, in practice, some pretty big chunks of functionality on the protocol level is missing but the freedesktop contributors, and the GNOME and KDE teams will get there eventually.

▲

WhyNotHugo 4 days ago | parent [-]

The fact that we need the entire xdg-desktop-portal stack for screen sharing on browsers is a major annoyance. We now have a standardised extension for screencasting and screencopy (formerly it was not standard, but had been around for years), but browsers only support the Flatpak stack, which has a lot of moving parts and IPC. Doing out-of-band IPC for this is kind of pointless when the client and the server already have a Wayland connection to begin with.

Outside of the domain of Firefox/Chromium, screencasting is much seamless. But 90% of the screen-sharing happens in browsers.

▲

thayne 3 days ago | parent | next [-]

> Outside of the domain of Firefox/Chromium, screencasting is much seamless

Not always. In my experience Zoom screencasting is much, much worse than on browsers in Wayland. But that isn't terribly surprising given how generally bad Zoom UX is on Linux.

▲

tristan957 2 days ago | parent | prev | next [-]

What is the flatpak stack? Even unsandboxed apps use the portals.

▲

mindcrash 4 days ago | parent | prev [-]

> but browsers only support the Flatpak stack

Well, I think you should blame Google and Mozilla for that.

KDE (through Discover, https://apps.kde.org/discover/) and GNOME (through Software, https://apps.gnome.org/Software/) both have innate support for Flatpak.

So, given that the majority of normie Linux users will use Flatpak to install a browser, they will just use and support that in the browser (because the underlying DE wil more than likely have Flatpak support integrated too) and go on with their day to day.

Means that people who don't want to deal with Flatpak have to deal with Flatpak (or at least parts of it) too unfortunately.

	▲	michaelmrose 4 days ago \| parent [-]
		Most distros come with Firefox which most normies will simply use as is. Also, software stores show both native and flatpak or on Ubuntu snap. One can easily install the system package of chrome if one doesn't want to deal with flatpak.