Relative paths in .desktop files

[David Faure]

On Thursday 23 June 2011, Marty Jack wrote:
> 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.

Well, this is just one use case.

What about the use case where I write a script and a .desktop file for my wife, 
which she can put in any directory she wants?
With a relative path I can now do that, and she can move the .desktop file and 
the script together and it will continue to work.
Without support for relative paths, this would break, just because the 
.desktop file requires an absolute path.

I believe this has more uses than installation kits / autorun.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).