drracket does not appear in application launcher on linux?

[jestarray]

I've recently upgraded from 8.8 to 8.17 and I use rofi + i3 on arch linux and I could not find drracket on rofi. racket and drrracket were installed in /usr/bin/ though. Something broke between 8.9 and 8.17 for it to not do the following:

The fix:
cp /usr/share/racket/pkgs/drracket-core-lib/drracket/drracket.desktop ~/.local/share/applications/

The drracket.desktop file is no longer copied into ~/.local/share/applications/ anymore? Can anyone confirm this on linux and other application launchers?

[jbclements]

Apologies if I'm missing something obvious here, but I think my first question is this: what method are you using to install (or upgrade) racket? Are you installing using an installer downloaded from racket-lang.org, or using the arch package manager? I'm guessing it would be the latter, and ... I feel like I should be able to find a web page with a big list of arch packages and their maintainers, and I'm not finding it. So: if this is coming from a package manager, can you see who's maintaining that package?

[jestarray]

I'm installing via package manager yes pacman -S racket:
https://archlinux.org/packages/extra/x86_64/racket/

The guy who's maintaining it seems to alternate sometimes but currently its: George Rawlinson

[maueroats]

The desktop file appears in the manifest: usr/share/applications/drracket.desktop.

It is not appropriate for a system-wide package to install into ~/.local.

You should check your $XDG_DATA_DIRS to make sure /usr/share is listed.

[LiberalArtist]

As @maueroats said, if DrRacket is installed in /usr/bin/drracket, then the .desktop file belongs in /usr/share/applications/drracket.desktop, which appears to be where Arch is installing it. (There are many ways of installing DrRacket into different scopes, but this is indeed the most likely one for a distro package.)

I use rofi + i3 on arch linux

One possibility: is there some hook for your desktop environment to rebuild launcher menus that may not be getting run when it should be? For example, as a KDE user, sometimes I need to manually run kbuildsycoca5 if I've changed my state in an odd way. If something like this is the explanation, ultimately it should probably be a packaging bug against some part of your distro tooling that should be running it when needed.

We'd definitely like to help you and/or your distro packagers get this working smoothly, but this is not an issue in general with free desktop application launchers.

---

You should check your $XDG_DATA_DIRS to make sure /usr/share is listed.

Having $XDG_DATA_DIRS unset should also work, because the default is /usr/local/share:/usr/share. But I'd be surprised if this were the problem, because I'd expect it to cause really dramatic symptoms, like nothing appearing in the application launcher.