Where to set $XDG_DATA_DIRS so that ilia sees it?

[brianalexander]

Using the latest install for Regolith for Ubuntu 24.04, $HOME/.local/share is not a default in $XDG_DATA_DIRS. Updating $XDG_DATA_DIRS in ~/.profile as recommended in some places does not appear to update the path in time for ilia to detect my desktop files.

Only after using sudo desktop-files-install to install the desktop file to /usr/share/applications, does it show up in the launcher. This is a little clunky as I have to sudo it.

Where should I update the path for $XDG_DATA_DIRS so that it'll be set in time for ilia?

Thanks!

[kgilmer]

Hi @brianalexander , I believe it will differ based on X11 or Wayland. Which are you running?

[onnodb]

Also running into this strange little issue on Ubuntu 22.04 / Regolith 3.2 / X11 session.

I've tried the following things to add my $HOME/.local/share directory to XDG_DATA_DIRS:

• Add it to the XDG_DATA_DIRS list from within my ~/.profile file.
• Define a ~/.config/regolith3/i3/env EnvironmentFile with the full XDG_DATA_DIRS definition.

When using Ilia as an app launcher from the i3 config (ilia -apps, bound to a hotkey), it obviously misses DESKTOP filles that are installed in ~/.local/share/applications. When manually running ilia -apps from within a terminal launched from i3, it does see those DESKTOP files.

So it also seems to me like I cannot quite get the XDG_DATA_DIRS definition quite in the right location to make the i3 "root" process aware of it.

I'd be grateful for any suggestions on where to make these updates!

[kgilmer]

Hi @onnodb , here is where the i3 process initiates in Regolith 3.2/X11: https://github.com/regolith-linux/regolith-session/blob/main/usr/bin/regolith-session-x11#L58

[onnodb]

Thanks for the additional info @kgilmer ! Using this as a starting point, I managed to troubleshoot my issue. I'm afraid I might have derailed this thread with something unrelated. My apologies!

---

Just in case it helps someone else:

By inspecting /proc/*/environ for the ilia processes spawned by i3 and my terminal, respectively, I noticed that both actually do see the correct XDG_DATA_DIRS environment variable. What was off, was the definition of PATH: somehow, the i3 root process hadn't picked up on the correct PATH. What then happens, is that ilia/GTK automatically filters out any DESKTOP files that do not have a valid Exec line (that is, their Exec line refers to an executable that is not found on the current PATH). So ilia simply does not show items in its Apps menu that won't be able to start.

(As a related symptom, I had noticed that some commands in my i3 config required a full path to be specified, whereas the executable ran fine without the full path from a terminal. This was also due to an incorrect PATH.)

It turns out that extending the PATH env var in my ~/.profile file didn't work: that value somehow gets overridden by something else in the session launch process. I don't fully understand why yet!

What solved it, was defining these overrides through a file in ~/.config/environment.d/user.conf (create this directory if needed; source):

PATH=${HOME}/.local/bin:${PATH}
XDG_DATA_DIRS=${HOME}/.local/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}

With this in place, ilia now sees both the correct PATH and the correct XDG_DATA_DIRS, and all is well :)

[nvarner]

I ran into this same issue. @onnodb's advice was very helpful; my problem was also PATH, not XDG_DATA_DIRS.

My PATH (and other environment variables) were being set by this invocation of /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator (for me on Wayland; presumably here for X11). Directly running

$ /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator

showed a good XDG_DATA_DIRS but a bad PATH. The more verbose

$ SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator

also traced the configuration files as they were loaded.

On my system, earlier files were setting up PATH correctly, but /usr/lib/environment.d/99-environment.conf was parsed near the end, and reset PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin. This file seems to be installed by default as a symlink to /etc/environment, which by default contains exactly PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin. This means any PATH configuration in a file ordered before 99-... will be ignored.

As a nonexpert here, I suspect that this is undesirable behavior, and that /etc/environment should be the first configuration file loaded, so that its defaults can be built upon by later configurations. Note also that /etc/environment is not part of systemd, is used for other things by other programs, and has a compatible but more restricted syntax than systemd's *.conf files. My understanding is that the symlink is a bit of a hack, but I'm not sure if it can safely be deleted, and I do not believe that /etc/environment should be directly modified to resolve this.

I fixed this by renaming the symlink so it was parsed earlier.

$ sudo mv /usr/lib/environment.d/99-environment.conf /usr/lib/environment.d/00-environment.conf

After logging out and logging back in, Ilia picks up my desktop files as expected, and /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator gives a more reasonable PATH.

Again, as a nonexpert, I don't know that this is the "right" fix (e.g. perhaps the symlink should be deleted, or other configuration files should be renamed to have a priority above 99), but it did work, and this does seem to be the root cause.