Bug 460238

SUMMARY
Preface: reporting under xdg-desktop-portal-kde despite this being of wider scope, and probably not related to the kde portal at all...

When multiple portals are installed, xdg-desktop-portal picks the best one for the current session based on $XDG_CURRENT_DESKTOP. But in a Plasma X11 session xdg-desktop-portal.service is started without such variable in its environment. So the portal falls back to choosing the implementation with alphabetical order, and gnome wins.

This only happens in Plasma X11, the variable (alongside the other XDG and /etc/profile.d/ variables) is picked up in a Plasma Wayland session. This happens both with and without systemdBoot.

xdg-desktop-portal-gtk is the only service that gets started with all my environment variables, where xdg-desktop-portal, xdg-desktop-portal-gnome, plasma-xdg-desktop-portal-kde are not

STEPS TO REPRODUCE
1. Install both xdg-desktop-portal-kde and xdg-desktop-portal-gnome
2. Fresh reboot (log-out and log-in causes a different behaviour...)
2. Log into a Plasma X11 session

OBSERVED RESULT
`xargs -0 -L1 -a /proc/$(pidof xdg-desktop-portal)/environ` does not contain XDG_CURRENT_DESKTOP.
A visible effect, for example, is that in flatpaks the file picker is GTK
Another important effect is that when an application is started as a result of opening a file from inside a flatpak, it will inherit an incomplete environment from xdg-desktop-portal. For example, opening a PDF from Telegram flatpak will make Okular not use the Breeze theme, and other applications may have other issues depending on what XDG environment variables they expect.

EXPECTED RESULT
More user environment variables are imported when starting xdg-desktop-portal, so that the correct portal implementation is picked, and a complete environment is used when forking.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 36 KDE
(available in About System)
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6

ADDITIONAL INFORMATION
As far as I understand xdg-desktop-portal is dbus-activated and its environment variables depend on the process that activates it. In my case that process seems to be early-started, before (who?) sets XDG_CURRENT_DESKTOP and friends.