Relative paths in .desktop files

Michael Thayer michael.thayer at
Mon Apr 11 13:42:24 PDT 2011

On Mon, 2011-04-11 at 13:30 -0400, Marty Jack wrote:
> On 04/11/2011 12:06 PM, Michael Thayer wrote:
> > --- desktop-entry-spec-1.1.xml	2011-04-11 17:50:02.350865289 +0200
> > +++	2011-04-11 17:57:39.126810018 +0200
> > @@ -429,7 +429,10 @@
> >  	    <entry>
> >            Icon to display in file manager, menus, etc.  If the
> >            name is an absolute path, the given file will be
> > -          used. If the name is not an absolute path, the algorithm described
> > +          used. If it starts with "./" it will be treated as a path
> > +          relative to the directory containing the desktop file and
> > +          the given file will be used. Otherwise, the algorithm
> > +          described
> Having thought about this just a moment more, I note that I forgot to
> mention the other main existing usage, Autostart, where the same
> considerations would apply.
> I wonder if there isn't an argument for a new Type= in order to
> differentiate this case where you have everything lumped into the one
> directory.  It feels quite distinct.
Actually to my mind the intent is the same (describing an application
plus how to locate its essential files on disk - even if in this
particular instance the application is an installer for another
application) but the context is different (an application installed in
the FHS/ layout relative to the filesystem root versus
one installed in an unspecified layout relative to a flexible point in
the filesystem hierarchy).  Using a new Type as you suggested
(Type=ApplicationRelative?  Or is that too ugly?) might indeed be more
sensible (and aesthetical) than the "./" prefix.  Someone might even
want to keep such a desktop file under <something>/share/applications
and have paths starting with "../.." ...

> There's nothing GNOME specific about this, and it should work on any
> DE.  The code you referenced is in glib, which just happens to be
> hosted on the GNOME site for historical reasons.
I was assuming that people would be happier if I submitted at least one
code patch as well, and GNOME is what most of our target users will be
running.  If other DEs are using the same code in glib, so much the
better.  I have no objections of course if this or something similar can
be adopted in the specification and the current DE code maintainers
quickly integrate it themselves!


ORACLE Deutschland B.V. & Co. KG   Michael Thayer
Werkstrasse 24                     VirtualBox engineering
71384 Weinstadt, Germany           mailto:michael.thayer at

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

More information about the xdg mailing list