Relative paths in .desktop files

[Marty Jack]

On 06/23/2011 06:47 AM, David Faure wrote:
> On Thursday 23 June 2011, Michael Thayer wrote:
>> On Thu, 2011-06-23 at 11:58 +0200, David Faure wrote:
>>> On Monday 18 April 2011, Vincent Untz wrote:
>>>> FWIW, I'd consider ./ to be relative to the path defined in the Path
>>>> key (which could be ./ to tell that it's the base directory of the
>>>> .desktop file).
>>>
>>> From a KDE point of view: I support these additions to the desktop entry
>>> spec and I volunteer to implement them in KDE.
>>>
>>> (In fact I just implemented support for Exec=./foo here, but that's
>>> useless by itself if it requires on a Path that has to be absolute, so
>>> the next step is to implement Path=. if we all agree on that syntax).
>>
>> Great.  Would you like me to post an updated patch against the spec, as
>> in e.g.
>> [ http://lists.freedesktop.org/archives/xdg/2011-April/011887.html ], or
> 
> Ah I seem to have missed some emails in this thread, thanks for the pointers.
> 
> I am definitely NOT in favour of Type=ApplicationRelative, this would require 
> many more adaptations to the code in many places, and it moves a rather 
> special case to a very proeminent place -- should we have 
> Type=ApplicationWithPath when Path is set, and Type=ApplicationWithTerminal 
> when a terminal should show up? Sorry for the reasoning by the absurd or 
> whatever that's called -- my point is that there's a combinatorial issue in 
> putting too much information into Type. This discussion is about a small 
> change in the file describing an application, let's keep Type=Application.
> 
>> does [ http://lists.freedesktop.org/archives/xdg/2011-April/011882.html
>> ] look good to you?
> 
> It says that "./" is relative to the location of the .desktop file. I can see 
> the idea behind it, but then what happens when Path is set?
> 
>>From an implementation point of view it's easier to chdir(Path) and then 
> execute ./foo, but I can see how from a user point of view the idea is maybe 
> more to say "resolve to a full path from the directory containing the .desktop 
> file, then chdir(Path), then run the executable with a full path"?
> 
> I'm talking about a case like /home/dfaure/foo.desktop saying:
> Exec=./foo
> Path=/tmp
> 
> Should this do (cd /tmp ; ./foo) or (cd /tmp ; /home/dfaure/foo) ?
> 
> I'm guessing the latter is more useful, but maybe less expected.
> 
> (More useful because the first one can be done with Exec=/tmp/foo, since in 
> that case we know about /tmp as an absolute path anyway).
> 

I continue to oppose this.  As I understand it, the intended use is for installation kits similar to how Autorun works on Windows.

I would also refer everyone to the Autostart spec
http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
which, in section Autostart of Applications After Mount, already deals with this after a fashion.  I am not convinced that definition does not suffer from the same problems I point out here.

The current way this proposal is defined is of no use for the existing applications of Desktop Entry, to wit the application menu (/usr/share/applications) and the X sessions menu (/usr/share/xsessions).

The current proposal breaks the separation between architecture independent items like the icon and architecture dependent items like the executable.

I would like someone to take me through how the multi-architecture scenario would work.  If Exec points to a relative path, how do we have an install kit that has a binary for x86, a binary for s390, and a binary for arm, all of which are currently important Linux architectures.