Relative paths in .desktop, .service files' Exec= lines

[David Faure]

Hi Simon,

Thanks for bringing this up again.

On lundi 20 juin 2016 18:24:58 CEST Simon McVittie wrote:
> My preferred proposal: relative to .desktop file
> ================================================
> 
> I think relative paths containing at least one path separator (slash on
> Unix, slash or backslash on Windows) should be treated as being relative
> to the directory in which the .desktop or .service file was found, while
> paths containing no path separators should have their current meaning
> from the Desktop Entry Specification, and so should absolute paths. This
> was suggested by KDE's Thiago Macieira during the previous discussion,
> and was also unanimous among GTK hackfest attendees. I'm going to
> propose Desktop Entry Specification and D-Bus Specification patches for
> this unless there is consensus on something better.

+1

> One subtlety of the phrasing is that a single .desktop or .service file
> might be visible in more than one directory thanks to symlinks, hard
> links or bind mounts. Thiago's phrasing makes it specific that it is the
> directory that actually appeared in the .desktop or .service search path
> that matters, and not any of the same file's other apparent locations.

+1

> For the somewhat obscure feature in which
> ".../applications/foo/whatever.desktop" is equivalent to
> ".../applications/foo-whatever.desktop", I don't really care whether the
> relative path is relative to .../applications or .../applications/foo. I
> would go for .../applications if I have to make an arbitrary decision,
> but I believe this feature was added to support something in KDE, so
> I'll defer to whichever one KDE developers would prefer.

I think there is confusion in this sentence.
There is no equivalence at the filesystem level. The equivalence is more along 
the lines of "when looking for foo-whatever, consider foo/whatever.desktop".
It has no impact on this suggested change, since it's well defined which file we 
actually found. And yeah we're mostly moving away from this anyway, with the 
new standardization on "org.kde.whatever.desktop" instead.

>[...]
> Are there any specific objections to this approach going into the
> Desktop Entry and D-Bus specifications?

Not from me. Allison, any objection?

Don't forget to mention how the working directory (Path=...) should be 
handled, as I pointed out in 24 June 2011 on this list about the same topic ;)
I.e. the executable will have to be launched with a full path, from the 
specified working directory.

> I'm assuming that GNOME programs do what GLib does, which is to look up
> executables relative to getcwd(). What do other major desktop
> environments like KDE do?

You mean right now? Right now KDE looks up "./foo" in the PATH and executes 
it, if found. However it's a rather strange way to specify an executable name, 
so I have no objection in this changing to be a relative lookup.

Implementation wise this isn't as trivial as it sounds, because desktop files 
(at least those installed into standard directories like XDG_DATA_DIRS/
applications) are collected into a DB which abstracts away where the desktop 
file came from... We'll have to look it up again. Anyhow I volunteer to 
implement this in KDE Frameworks 5 once it's in the spec.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5