8

I've written quite a few open source programs over the years, but not very recently, and I've never had this problem before. The menu items for my new project simply refuse to show up in menus on either gnome or kde.

I originally just installed the .desktop files to /usr/share/applications but later modified it to use desktop-file-utils - all to no avail. I've add update-desktop-database to my postinst script... nothing

I've validated the entries, and in the file manager they are correct, I've tried giving them execute permissions... I can't find anything wrong but they just won't show up. Is there something new one has to do to get your app's menu items to show these days ?

The .desktop files are:

silentcoder@ravenriley ~/SOURCE/ezdm $ cat ezdm.desktop 
[Desktop Entry]
Type=Application
Name=EZDM
GenericName=Easy Dungeon Master
Comment=A tookit for AD&D Dungeon Master
TryExec=/usr/games/ezdm
Exec=/usr/games/ezdm
Categories=Game;RolePlaying;
Icon=/usr/share/icons/hicolor/128x128/ezdm.png
Terminal=false

cat ezdmconsole.desktop 

[Desktop Entry]
Type=Application
Name=EZDM-Console
GenericName=Easy Dungeon Master (Console version)
Comment=A tookit for AD&D Dungeon Master
TryExec=/usr/games/ezdm --console
Exec=/usr/games/ezdm --console
Categories=Game;RolePlaying;
Icon=/usr/share/icons/hicolor/128x128/ezdm-console.png
Terminal=1
X-Desktop-File-Install-Version=0.20

And if any of the other code might be useful, it's all browseable on github: https://github.com/ajventer/ezdm

UPDATE: The mystery deepens, if I copy the files to /usr/share/applications/kde4 (which I obviously don't want to do in my package - after all, it should work in gnome too) then suddenly ezdm.desktop does show up in the menu, but ezdm-console.desktop still refuses to.

UPDATE: since it may be relevant: From Makefile:

install:
                $(PYTHON) setup.py install --prefix=/${PREFIX} --root $(DESTDIR) --install-scripts=/${PREFIX}/games/ --no-compile --force --record .install.record --install-layout=deb
                mkdir -p ${DESTDIR}/${PREFIX}/share/applications
                mkdir -p ${DESTDIR}/${PREFIX}/share/icons/hicolor/128x128/
                desktop-file-install --dir=${DESTDIR}/${PREFIX}/share/applications/ ezdm.desktop 
                desktop-file-install --dir=${DESTDIR}/${PREFIX}/share/applications/ ezdm-console.desktop 
                install -g root -o root -m 0666 ezdm.png ${DESTDIR}/${PREFIX}/share/icons/hicolor/128x128/ezdm.png
                install -g root -o root -m 0666 ezdm-console.png ${DESTDIR}/${PREFIX}/share/icons/hicolor/128x128/ezdm-console.png 
                update-desktop-database ${DESTDIR}/${PREFIX}/share/applications

And debian/postinst:

cat debian/postinst 
#!/bin/bash -x
ln -sf /usr/games/ezdm* /usr/bin
for I in /usr/lib/python2.7/dist-packages/ezdm_libs/*.py; do
        python -m compileall $I
done
update-desktop-database
#DEBHELPER#
Improve this question
  • I am not sure where the problem is - it could very well be the install code, since the possibilities are scattered over numerous places - I gave one set of examples and linked to where all the other code is. But by all means, I'll add the makefile and setup.py as well. – silentcoder Feb 28 '13 at 23:42
  • Did you have a look at stackoverflow.com/questions/13632385/… – mikebabcock Feb 28 '13 at 23:59
  • Yep, found it while googling around - I even mention in the question that I tested with giving +x permissions (the solution from that question) – silentcoder Mar 1 '13 at 0:02
  • So it shows up in KDE but not in GNOME? – user13742 Mar 1 '13 at 0:02
  • I haven't checked that - I was just trying to various things. But installing to a KDE4 specific directory would be insane either way - since this should work on any desktop that understands the XDG specification - they can't all demand a different menu directory. – silentcoder Mar 1 '13 at 0:04
6

There is very insidious desktop file key - TryExec. According to docs:

TryExec

Path to an executable file on disk used to determine if the program is actually installed. If the path is not an absolute path, the file is looked up in the $PATH environment variable. If the file is not present or if it is not executable, the entry may be ignored (not be used in menus, for example).

So, it may result in missing menu entry if it is not filled properly. And by "properly" I mean that it always must point to actual executable.

Surprisingly, if you trying to launch your program in modified environment using env, it stops working. Here is example of invalid desktop file from my distro's package:

TryExec=env FONTCONFIG_FILE=/usr/share/fonts/fonts.conf telegram -noupdate
Exec=env FONTCONFIG_FILE=/usr/share/fonts/fonts.conf telegram -noupdate -- %u

It doesn't work because DE looks for env FONTCONFIG_FILE=/usr/share/fonts/fonts.conf telegram -noupdate executable, treating whole string (including spaces) as file path, which is missing, of course.

The solution is also simple: just specify path to actual executable (even relative):

TryExec=telegram
Improve this answer
  • To add to this answer: my ".desktop" file had an Icon entry that pointed to a file that did not exist. This prevented the entry from showing up at all in my menus. – csd Jul 3 '20 at 17:42
  • A couple of other useful points which may help others. There are two utilities in [freedesktop.org/software/… which are useful. From the description: This package contains desktop-file-validate which checks whether a .desktop file complies with the specification at freedesktop.org/standards, and desktop-file-install which installs a desktop file to the standard directory, optionally fixing it up in the process. – Brian Redbeard Nov 4 '20 at 20:04
  • I've tried desktop-file-validate on my "broken" file. Unfortunately, it vilidates file without any issues. These utilities are very useful, though. – tosh Nov 4 '20 at 20:26
3

There were formatting errors in the files. Based on commenters, I can only assume that some versions of gnome are more forgiving. Either way I found a nifty way to get them to work: Open the directory in dolphin, and edit them until they can be launched from dolphin - only once that works, add the categories field and then they show up in menus. In KDE you may have to run: kbuildsycoca4 --noincremental first if you don't relog.

The final versions of the files are:

cat ezdm.desktop 
[Desktop Entry]
Categories=Game;RolePlaying;
Comment[en_US]=A tookit for ADnD Dungeon Master
Comment=A tookit for ADnD Dungeon Master
Exec=/usr/games/ezdm
GenericName[en_US]=Easy Dungeon Master
GenericName=Easy Dungeon Master
Icon=/usr/share/icons/hicolor/128x128/ezdm.png
MimeType=
Name[en_US]=EZDM
Name=EZDM
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
TryExec=/usr/games/ezdm
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=

silentcoder@ravenriley ~/SOURCE/ezdm0/ezdm $ cat ezdm-console.desktop 
[Desktop Entry]
Categories=Game;RolePlaying;
Comment[en_US]=EZDM Console Version
Comment=EZDM Console Version
Exec=/usr/games/ezdm --console
GenericName[en_US]=EZDM Console Version
GenericName=EZDM Console Version
Icon=/usr/share/icons/hicolor/128x128/ezdm-console.png
MimeType=
Name[en_US]=EZDM-Console
Name=EZDM-Console
Path=
StartupNotify=true
Terminal=true
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
X-KDE-SubstituteUID=false
X-KDE-Username=

In case that helps anybody else. I've just pushed out a new PPA build request, so updated ubuntu packages will be available soon.

Improve this answer
3

try this:

xdg-desktop-menu forceupdate [--mode mode]

out of

man xdg-desktop-menu
Improve this answer
  • 1
    Referencing a man page is a good start, but you may want to consider quoting the most relevant bits inline for succinctness's and completeness's sake. – HalosGhost Jul 9 '14 at 7:11
0

Most likely because your incorrect TryExec line indicates that it is no longer valid.

TryExec=/usr/games/games/ezdm

I guess this file does not exist, and in particular is not executable?

Improve this answer
  • Thanks for that catch, I've fixed it in the code, but the menu items still don't show up (I even logged out and back in to make sure). – silentcoder Feb 28 '13 at 23:16
  • Do you by chance have another ezdm.desktop somewhere, for example in $HOME/.local/share/applications/ezdm.desktop? – Has QUIT--Anony-Mousse Mar 1 '13 at 0:03
  • None that I can find, the only entries in the .local version are the ones wine creates. And I tested on another machine (with gnome) which does not contain a code checkout (I use it to clean-install test the packages). – silentcoder Mar 1 '13 at 0:06
0

At least on Ubuntu 19.10, one possible cause is that the binary referenced by Exec doesn't exist on the $PATH. This is true regardless of your TryExec line; you need both lines to refer to executables that exist on $PATH, or your application won't show in the application menu.

So: double-check you haven't typoed the executable at the start of your Exec= line and that it really exists.

Improve this answer
0

Except the syntax mistakes in .desktop files, I have to say, not every .desktop file in /usr/share/applications must show up in launcher menu all along.

There are a set of complicated rules to determine which .desktop files should be listed in launcher menu which are published in xdg docs:

https://www.freedesktop.org/wiki/Specifications/menu-spec/

Improve this answer
-1

Click here to know what is an application.desktop file.

Solution:

The file should exist in your computer already if the program is installed, so there should be no need to write another one. The problem is that is not in the directory that you need it to be to show up on your gnome-shell. Run the following if you want if not all almost all your application.desktop files to show up in gnome-shell. If you have not installed find install it according to your distribution's best practices. In my case: sudo apt-get install find. 


  # change the value of LOOKHERE for any directory
  LOOKHERE=/etc  ;
  for p in `sudo find * "${LOOKHERE}" | grep -E *\\.desktop$`; do
      sudo cp  ${p}  $HOME/.local/share/applications/ ;
  done

find * "${LOOKHERE}" | grep -E *\\.desktop$

The last should out put something like if LOOKHERE is /share:

/usr/share/gnome/autostart/nautilus-autostart.desktop
/usr/share/gnome/autostart/gnome-user-share-obexpush.desktop
/usr/share/gnome/wm-properties/metacity-wm.desktop
                           .
                           .
                           .
/usr/share/tracker/miners/tracker-miner-applications.desktop
/usr/share/tracker/miners/tracker-miner-userguides.desktop


Warning:

The variable LOOKHERE when set to / alone will look inside any removable media as well and those files could be pointing to non existent programs on your local machine. Make sure any exec statements are cross check with which application-name that should return your valid exec statement like which bash returns /bin/bash. If which do not work check whereis to start. For more advance changes use dconf or gsettings.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.