us.zoom.Zoom VS xdg-desktop-portal-gtk

For example, let's say we want a separate instance of Zoom (Zoom on Flathub) to run along the default one.

It seems to divert the discussion to something that doesn't make too much sense. X and Wayland are two different things by design, this probonopd sounds extraordinarily salty that moving an application under a new server breaks some things, making some applications entirely useless, but I say, that is to be expected. Saying that Wayland breaks stuff by design, as if that was their only objective is just petty, of course it's a pity that those devs have thrown in the towel, but let's not pretend like theirs were the only options, e.g. screen recording works perfectly fine with OBS, at least it has done so on my machines with AMD/Intel GPUs; Jitsi works now; Zoom screensharing being GNOME only is Zoom devs being dicks that can't be arsed to support standards, the community came in to work around it and also I don't know how they could bring up a proprietary application that has not made the Flatpak package themselves as an example, the whole thing is a community effort there apparently; etc. etc. (I'm not going to debunk all the others that are invalid, the internet is there for everyone)

Can you be specific about the problems with X11? I've been using X11 for decades and it's been ROCK SOLID. And that is exactly what you want from something so essential. Wayland feels like an expensive boondogle, frankly. Wayland breaks everything and only provides 20% the functionality that X11. It also forces application and DE developers to implement special tools and solutions for wayland which have always been provided as a common interface by X11, like screenshots/ recording and screen sharing, e.g. https://github.com/flathub/us.zoom.Zoom/issues/22

For college and therapy, I've had to use Zoom. I've been using the zoom flatpak, as I try and use flatpak for any proprietary software. That being said, it is not officially supported (by zoom), and also doesn't listen to Pop!_OS's tiling window manager. Certainly, I'm not the only one who has questioned which client to use, but I'm curious what y'all think. I like flatpak because I can trust that, worst case scenario, the proprietary software (read: Spyware) only has access to a limited amount of my system. But it'd also be nice to, ya know, use the tiling feature.

I've gathered a coredump and a stack trace, which might be useful.

You can get it as a flatpak too which should (presumably) take care of any dependencies automatically. :)

Here you go: https://flathub.org/apps/details/us.zoom.Zoom

Check this out https://github.com/flathub/us.zoom.Zoom/blob/master/zoom.sh

Link to the github issue for the flatpak

I came across this, could this be playing a role? If it fixes Fedora 37 then it would be a clue and perhaps then the package could enter the string itself? https://github.com/flatpak/xdg-desktop-portal-gtk/issues/72

However, the actual dialogs and access points are provided by a backend, which differs from what desktop are you using. For example, Gnome uses xdg-desktop-portal-gtk, KDE uses xdg-desktop-portal-kde and so on.\ If there is an issue with the implementation of an portal, you need to find the backend you use and report it to them.

Is the Web search provider enabled in Settings? Those can apparently trigger background detection: https://github.com/flatpak/xdg-desktop-portal-gtk/issues/293

That sounds like https://github.com/flatpak/xdg-desktop-portal-gtk/issues/137

gui-libs/xdg-desktop-portal-lxqt Available versions: 0.2.0 Homepage: https://lxqt-project.org/ Description: Backend implementation for xdg-desktop-portal using Qt/KF5/libfm-qt gui-libs/xdg-desktop-portal-wlr Available versions: 0.4.0(0/9999) 0.5.0(0/9999) ~0.6.0(0/9999) **9999(0/9999)*l {elogind systemd} Homepage: https://github.com/emersion/xdg-desktop-portal-wlr Description: xdg-desktop-portal backend for wlroots [I] kde-plasma/xdg-desktop-portal-kde Available versions: (5) 5.24.6 ~5.25.4 {debug} Installed versions: 5.24.6(5)(01:02:06 07/29/22)(-debug) Homepage: https://kde.org/plasma-desktop Description: Backend implementation for xdg-desktop-portal that is using Qt/KDE Frameworks [I] sys-apps/xdg-desktop-portal Available versions: 1.14.6 {geolocation screencast systemd} Installed versions: 1.14.6(20:25:44 08/27/22)(-geolocation -screencast -systemd) Homepage: https://flatpak.org/ https://github.com/flatpak/xdg-desktop-portal Description: Desktop integration portal sys-apps/xdg-desktop-portal-gnome Available versions: 42.3 {X wayland} Homepage: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome Description: Backend implementation for xdg-desktop-portal using GNOME sys-apps/xdg-desktop-portal-gtk Available versions: 1.8.0 1.14.0 {X wayland} Homepage: https://flatpak.org/ https://github.com/flatpak/xdg-desktop-portal-gtk Description: Backend implementation for xdg-desktop-portal using GTK+ Found 6 matches

you still xdg-desktop-portal-wlr in sway for screen sharing. the purpose of the gtk portal on non-gnome setups is to pass through some gtk settings (e.g. fontconfig, aliasing, gtk theme) to flatpak apps. your gtk flatpak apps won't follow the system theme and fontconfig unless you have the xdg-desktop-portal-gtk installed. right now it's borked though see below for more details - https://bugs.archlinux.org/task/72686?project=1&string=xdg-desktop-portal-gtk - https://github.com/flatpak/xdg-desktop-portal-gtk/issues/360