Using NixOS with Home-manager (unstable channel). One little pain point I have right now is that these websites that advertise themselves are installable apps (I am using Brave but the same applies to most chromium browsers I suppose) are sometimes removed by what I think is the nix garbage collector.
Is it a known issue? I’d like to prevent that from happening. I guess these installable apps are little beyond a handful of resource files + symlinks stored something in $HOME, yet they are perceived at some point as dead symlinks and thus gc’ed.
Installable webapps are not symlinks and don’t store any local resources, they are just .desktop files that start your browser with specific flags.
The nix garbage collector only touches paths in /nix/store, anyway, not random symlinks lying around everywhere on your system, there’s no way it would delete things from your home directory.
I see that the .desktop files are there sitting on ~/Desktop (an callable from brave://apps) but that I can no longer call them using the GNOME app launcher. (this thing:
) and when invoked from brave://apps they are considered by Alt-tab as mere browser windows (they no longer have their own icon).
Since the app launcher makes use of .desktop it founds in various places, my hunch was that the .desktop files it uses for my installable apps are gc’ed, in which case they probably were symlinks to the original files sitting in ~/Desktop.
If this is incorrect, what else could be the culprit?
Sounds to me like whatever variable added ~/Desktop to the set of directories GNOME will look for .desktop files in changed.
By default, it’s supposed to look in ~/.local/share/applications - or specifically, I think all applications subdirectories of the directories in $XDG_DATA_DIRS and $XDG_DATA_HOME, which defaults to ~/.local/share and some system paths that users shouldn’t normally write to.
This is because when nix updates an application, its path in the nix store will get a new hash. So when you update your system, this .desktop would need to be updated to point to the new brave - but it is not, since nix is not aware of it.
That then means that when you open that .desktop you launch an older version of brave.
I believe it still “works” - but shows up as an empty application with no icon - because the old version has not yet been garbage collected, but browsers use an API to open additional webpages in an already running instance of themdelves. Or perhaps the icon for this binary is simply no longer on your system post update.
Either way, you don’t want to be using the old brave, so you should set the browser to be looked up in your path. That way whatever browser is currently installed will be used, and not some potentially outdated or completely absent one.
I do, and having now actually read the issue, I don’t really think upstream can fix this without breaking other use cases (like not having chromium on $PATH at all), so the patch suggested in the issue is not just appropriate but necessary.
It’ll break ssb things for people who don’t add chromium to their path, but those were already going to break eventually anyway.
