Relative paths in .desktop files

[Marty Jack]

On 04/11/2011 12:06 PM, Michael Thayer wrote:
> Hello Marty,
> 
> On Mon, 2011-04-11 at 11:11 -0400, Marty Jack wrote:
> [...]
>>>>> On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer
>>>>> <michael.thayer at oracle.com> wrote:
>>>> [...]
>>>>>  I immediately ran up against the
>>>>>> problem that all paths in .desktop files have to be absolute, which
>>>>>> obviously isn't an option here.
> [...]
>> I still have not seen a crisp definition of what you are proposing
>> that a relative path specification mean.  The question "relative to
>> what" has not been answered.  If you were to propose some specific
>> text change that could be commented on, in sufficient detail that its
>> implementation is unambiguous, that would help a lot.
> Thanks for the answer.  Please find a patch against
> desktop-entry-spec-1.1.xml below.  I hope that that, together with my
> initial posting, makes my intentions slightly clearer.  As I said, I
> would also interested in other approaches to achieve the same thing.
> 
> By the way, google has already answered my question about where in the
> GNOME source code desktop files are handled
> ([http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c]).  I
> would probably not want to attempt anything for other DEs just now.
> 
> Regards,
> 
> Michael
> 
> --- desktop-entry-spec-1.1.xml	2011-04-11 17:50:02.350865289 +0200
> +++ desktop-entry-spec-1.1.xml.new	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
>  	  in the <ulink
>  	  url="http://freedesktop.org/wiki/Standards/icon-theme-spec">Icon
>  	  Theme Specification</ulink> will be used to locate the icon.
> @@ -471,10 +474,12 @@
>  	    <entry id="key-tryexec"><varname>TryExec</varname></entry>
>  	    <entry>
>            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).
> +          is actually installed. If the path is not an absolute path and does
> +          not start with "./", the file is looked up in the $PATH
> +          environment variable. Paths starting with "./" are treated as being
> +          relative to the directory containing the desktop file. If the file
> +          is not present or if it is not executable, the entry may be
> +          ignored (not be used in menus, for example).
>  	    </entry>
>  	    <entry>string</entry>
>  	    <entry>NO</entry>
> @@ -572,7 +577,9 @@
>        The <varname>Exec</varname> key must contain a command line.
>        A command line consists of an executable program optionally followed
>        by one or more arguments.
> -      The executable program can either be specified with its full path or
> +      The executable program can either be specified with its full path,
> +      with a path starting with "./" which is treated as relative to the
> +      directory containing the desktop file, or
>        with the name of the executable only. If no full path is provided the
>        executable is looked up in the $PATH environment variable used by the
>        desktop environment.

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.

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.