Relative paths in .desktop files
martyj19 at comcast.net
Thu Jun 23 05:00:11 PDT 2011
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:
> 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
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.
More information about the xdg