Version independent location for `.desktop` files

I’m not sure if this qualifies as a bug, or just something I’m doing wrong, but whenever I set a desktop application to autostart on login (in Plasma DE), like yakuake for instance, it works fine until the next time the application is updated; the application no longer autostarts until I manually add it to the list of applications to autostart.

The reason why this is happening is clear enough: KDE autostarts applications by placing a symlink to the desktop file of the application in ~/.config/autostart. In this particular case, the symlink points to wherever in the nix store the desktop file is, e.g. /nix/store/02s2jnj170rlb8kyxhby3ccjdmfswlil-yakuake-3.0.5/share/applications/org.kde.yakuake.desktop. Obviously, this location changes whenever the application or one of its dependencies is updated, which breaks the symlink.

One unstable workaround for this problem is to manually replace the symlink in ~/.config/autostart with the actual .desktop file. While this works in theory, in practice it means that the .desktop file used to launch the application may no longer be up to date once the application is updated. Another workaround might be to have a common location for all the current .desktop files, much like how /run/current-software/bin houses all the currently active binaries.

Being new to Nix and NixOS, I don’t know what the recommended workaround for this problem is, and I also don’t know how I’d go around implementing the second workaround. I’d appreciate any opinions or advice. Thanks!

1 Like

I think this might be a bug in how Plasma treats autostarts, because for me in GNOME the file is just plainly copied and isn’t a symlink.

And all .desktop files are linked at /run/current-system/sw/share/applications.

I have the same problem. Is there a canonical solution for linking programs persistently in KDE’s autostart?

Best option is probably to symlink the file from /run/current-system/sw/share/applications to ~/.config/autostart.

It turned out, that this was a case of PEBKAC. I was looking for a way to auto start Signal (the messenger) and was looking for the executable signal in /run/current-system/sw/bin/ but it is actually signal-desktop. It was there all along.