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.

Now we have something to discuss.  Your proposed change is crisp and unambiguous.

My first observation is that this new definition is in no way useful for existing .desktop files as used in application menu processing or in the available sessions menu (/usr/share/xsessions).  We should never expect to have executables in a /share directory because they are architecture specific and the desktop file is architecture independent.  By convention icons are either somewhere under /share/icons or in /share/pixmaps and located via the Icon Theme specification.  This is done this way so that themes can supersede the application supplied icon.

That being said, I am not certain this belongs in the Desktop Entry specification.

If this were added I think we need a statement in the Menu specification that this construction is not allowed in those .desktop files.

Your intended usage sounds more along the lines of an Autorun file.  Maybe you should call it autorun.inf and put whatever you like in it.