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.