Application entries (.desktop) not displayed

Desktop
1

Hi, for some time now (but I don’t remember how long) I’ve noticed that my .desktop entries are not displayed in the list of applications.

As a concrete example, recently I installed a very nice image viewer called “emulsion” (github ArturKovacs/emulsion) via rust cargo tool. It gets installed in ~/.cargo/bin which is in my path. I’d really like to choose it as my default viewer via “righ click/Open With Other Application” but it does not appear there. So I thought that if I’d make a desktop entry for it, it would show up in the list of applications to choose from. Problem is I’m not successful in doing it.

Here is the content of the file ~/.local/share/applications/emulsion.desktop

[Desktop Entry]
Type=Application
Name=Emulsion
Comment=A fast and minimalistic image viewer
GenericName=Image viewer
Exec=emulsion
Terminal=false
Categories=Graphics;

I’ve tried following both gnome help page https://developer.gnome.org/integration … es.html.en and arch instructions https://wiki.archlinux.org/index.php/desktop_entries but nothing seems to be working. desktop-file-validate is happy about it but whatever I do, it does not show up in gnome applications.

Any idea of what I can do? I feel like my issue is not specific to this entry since I’ve not being successful with any entry I added myself. Any pointer to how I could figure out what is wrong?

Gnome shell version: 3.36.3 (on X, not wayland)
Archlinux, Kernel: 5.4.48-1-lts

2

That entry is incapable of opening files, so can’t “Open With”.

The Exec should have a %u where the uri should be passed, and a MimeType key listing the types it can open

A quick search of that apps repo turned up a relevant issue Ship a .desktop file on Linux · Issue #86 · ArturKovacs/emulsion · GitHub

3

Thanks for clarifying that. Actually, I’ve also tried my luck in the arch forum (https://bbs.archlinux.org/viewtopic.php?id=256867) where someone pointed out that the AUR has a package with desktop entry of that form with %U argument and mime types. So I’ve also tried it, without success. It doesn’t even show up in gnome application, even after a reboot. That’s why I’m wondering if the issue might be related to something else. Maybe a setup somewhere I’ve changed by mistake? Could there be anything (apart from bad syntax file) preventing those from showing up in gnome applications?

4

have other .desktop files there (in ~/.local/share/applications) but none are showing up.

Well that’s worth mentioning I think…

Have you changed XDG_DATA_HOME or something?

5

When I do echo $XDG_DATA_HOME it’s empty. Same for XDG_CONFIG_HOME and XDG_CACHE_HOME but XDG_RUNTIME_DIR seems ok. I suppose this is a problem then? Where are those traditionally set?

6

No, the spec mandates a default value of $HOME/.local/share if $XDG_DATA_HOME isn’t set. So the location should be fine.

There are a number of additional checks, for example that all specified executables (TryExec or Exec) can be found in the path and have the executable bit set.

Could that be the problem? Maybe ~/.cargo/bin is only added to the PATH for interactive shells?

If you have debug symbols for GIO available, here’s an idea to debug the issue:

  1. Run
    $ gdb --args gjs -c "imports.gi.Gio.DesktopAppInfo.new('emulsion.desktop')"
  2. Set a breakpoint and run the program:
    (gdb) break g_desktop_app_info_load_from_keyfile
(gdb) run
  3. If the breakpoint isn’t hit, then the file is not found. Otherwise you can use the next and step commands to (hopefully) figure out where things go wrong
7

Thanks a lot @fmuellner! Apparently I don’t have debug symbols, which I guess is normal for programs installed from system repository (with pacman). But you were right about ~/.cargo/bin not been in the path for non interactive shell. Basically I used Exec=/home/matthieu/.cargo/bin/emulsion %F and now it shows up and I feel stupid for not having tried that earlier!

Also apparently I can’t use ~/.cargo/bin or $HOME/.cargo/bin since ~ and $ are not recognized in there but that’s just minor annoyance.

8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.