Dear Maintainer,

I tried to `flatpak --user update` and I got this message.
I think flatpak should be added by default to the XDG_DATA_DIRS env.

I think flatpak is a very nice piece of technology.

```sh
▶ flatpak --user update

Note that the directories

'/var/lib/flatpak/exports/share'
'/home/ieugen/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

Looking for updates…
Nothing to do.
```
My XDG_DATA_DIRS looks like this:
```
▶ env | grep XDG_DATA_DIRS
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
```

I switched to Plasma under Wayland recently, don't know if it is important. I'm
running Debian Buster (mostly) with some third party packages and some from
sid.

Control: retitle -1 flatpak directories not added to XDG_DATA_DIRS on Plasma + Wayland
...

This presumably means your session startup won't source
/etc/X11/Xsession.d/20flatpak like an X11 session would. GNOME in Wayland
mode doesn't do that either, so at least they're consistent.

Setting environment variables during session startup is, unfortunately,
still a bit of a mess. Flatpak tries to add its directories to
XDG_DATA_DIRS in several ways:

- /etc/X11/Xsession.d/20flatpak (X11-specific)
- /etc/profile.d/flatpak.sh (shell-specific)
- /usr/share/gdm/env.d/flatpak.env (GNOME/GDM-specific)

but apparently Plasma in Wayland mode doesn't use any of those.

Perhaps the answer is for Flatpak to have a systemd environment generator,
systemd.environment-generator(7), instead of or in addition to the
hooks we currently have? That would leave out sysvinit users, but that
isn't necessarily a huge problem, because they probably aren't using
Wayland anyway.

Or if there is a Plasma-specific mechanism similar to the GDM-specific
/usr/share/gdm/env.d (which is used by GNOME in Wayland mode) then
Flatpak could use that too, but I'd need details of that mechanism.

    smcv

Actually, it has had one of these since 1.1.3, so that can't be it. Please
check whether /usr/lib/systemd/user-environment-generators/60-flatpak is
getting run when you log in?

    smcv

Dear Maintainer,

I had the exact same problem immediately following installation of the
flatpak deb package, in that XDG_DATA_DIRS had not been altered.
Following a reboot, however, both the local and system
flatpack/exports/share directories were prepended to XDG_DATA_DIRS
(maybe due to /usr/lib/systemd/user-environment-generators/60-flatpak).

If I experienced the same problem the earlier reporters did, perhaps the
solution is to (a) warn the users that a reboot (or just a fresh log in)
is necessary for the XDG_DATA_DIRS variable to be updated, or perhaps
(b) so something clever to adjust the XDG_DATA_DIRS variable during
package installation.

Hi,

unfortunatly, this is still an issue with Plasma. As previously noted,
this should be covered by the user-environment-generator, but it seems
Plasma isn't using those by default (or their result isn't propagated?),
since it's not integrated in the systemd user session. This can be
actived by:

kwriteconfig5 --file startkderc --group General --key systemdBoot true

This makes the environment generator work.
https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot
suggests distros not enable this by default, since it breaks drkonqi :(

Until this becomes the default, maybe add a file
/etc/xdg/plasma-workspace/env/flatpak.sh with the content:

    eval `GIO_USE_VFS=local flatpak --print-updated-env`
    export XDG_DATA_DIRS

This should add the missing configuration to all new Plasma sessions.

See also:
- https://userbase.kde.org/Session_Environment_Variables/en
- https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma.cpp#L284-301

Best regards, Tobias