Keep in mind that the FreeDesktop standard is just that: a standard.
In principle a vendor
such as KDE, GNOME, LXDE, or XFCE could add support for relative paths
without going through the standards process,
but in practice none of them have.
(I know for sure that neither GNOME 3.28.2
nor KDE Plasma 5.12.9 support relative paths,
and to the best of my knowledge
no other desktop environment does either.)
Why is this?
Reason 1: The simplest version of relative paths would conflict with the existing standard.
Consider this desktop file:
[Desktop Entry]
Type=Application
Name=My example app
Exec=my_example_app
Icon=example-app
The FreeDesktop specification says:
Standard Keys
Icon
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 in the Icon Theme
Specification will be
used to locate the icon.
[ . . . ]
Values of type iconstring are the names of icons; these may be absolute
paths, or symbolic names for icons located using the algorithm described in
the Icon Theme
Specification. Such
values are not user-displayable, and are encoded in UTF-8.
Since example-app is not an absolute path,
menus and panels that want to display the icon
will follow the icon theme specification
to find the correct path,
usually by looking in a folder like
/usr/share/icons/hicolor/48x48/apps/example-app.png
However, example-app is also a valid relative path,
so the icon string is now ambiguous.
If one desktop environment adopts relative paths and the others don't,
it would break compatibility.
Similarly, consider the Exec key:
Exec=my_example_app
According to the spec,
it must be either a full path (i.e. absolute path)
or an executable in $PATH:
The Exec 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 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.
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables
So my_example_app should be looked up in $PATH,
but if we consider this a relative path,
we'll have to look somewhere that might not be in $PATH at all.
Which one gets precedence?
Now, perhaps we could require all relative paths
to be prefixed
with ./ to disambiguate them.
Since / is not allowed in filenames,
this wouldn't be ambiguous, e.g.:
Icon=./example-app.png
Exec=./my_example_app
for a file in the same working directory or
Icon=./../example-app.png
Exec=./../my_example_app
for a file in the parent directory.
This brings up another question:
what counts as the working directory?
Reason 2: The intended working directory for a desktop file may be unclear.
Desktop files
can set the working directory with the Path key:
Path
If entry is of type Application, the working directory to run the program
in.
So if a desktop file had a valid Path key
and were to specify a relative path like this:
Path=/home/username/path/to/myfolder/
Exec=./my_example_app
would that be relative to the location of the desktop file
or relative to the Path key?
There are other possibilities to consider.
Should the paths be relative to $XDG_DATA_HOME?
This would make some sense
since it's where the actual desktop files and icons are stored,
but it's not where the executables are stored.
Should the paths be relative to the working directory of the launcher process?
This would make sense
since this process that shows the panels or menus
is the one that needs to know where the executable and icon is.
Usually the working directory of the window manager
is the user's home directory,
but in principle the working directory could be anywhere.
Reason 3: Relative paths must be updated if the desktop file is moved.
OK, let's suppose we specify
that the paths to both the executables and icons
are always relative to the desktop file,
ignoring the Path key, the launcher process, and everything else.
Now suppose we want to copy that desktop file somewhere else, such as:
~/Desktop/example-app.desktop
Now the relative path is different,
and we'll have to edit the desktop file
and change the path all over again.
Using either absolute paths or standard folder locations
solves this problem.
Reason 4: Menus and panels may require desktop files to be in arbitrary locations.
As long as we keep the desktop file in the same directory
and only run it with the file manager,
relative paths will work.
But suppose we want to run our desktop file
from a menu or panel launcher.
Now the desktop file might be in
/usr/share/applications/
or it might be in
~/.local/share/applications/
or in
~/.config/xfce4/panel/
and note that the relative path to an icon or executable
is not the same for any of these.
Moreover,
depending on $XDG_DATA_HOME
and $XDG_DATA_DIRS,
the desktop file could be somewhere else entirely.
In the original question,
the stated use-case is to run executables from the GUI
and display custom icons without installing.
with executables not being easily startable from the GUI otherwise
and many launchers not using the app icon but only the icon specified
in the .desktop file.
Why then, does it not seem possible to use .desktop files that
specify a relative path to their executable and is there a way around
this?
When shipping software that one does not want to force users to
install, relative paths are the only way to enable this.
One reason why we bother with
a standard installation process for software in the first place
is to place resources in a standard location
so that other processes can find them.
This makes installing and uninstalling more complicated,
but helps with things like caching and debugging
since there's fewer directories to check.
If we don't want to install the executable,
we can still run it via a relative path,
but if we want the convenience of launching it
via another process (e.g. a menu launcher or panel),
the other process has to know where to look,
and since each process has its own working directory,
their relative paths may be different.
The spec has this to say:
So, you're an application author, and want to install application
icons so that they work in the KDE and Gnome menus. Minimally you
should install a 48x48 icon in the hicolor theme. This means
installing a PNG file in $prefix/share/icons/hicolor/48x48/apps.
Optionally you can install icons in different sizes. For example,
installing a svg icon in $prefix/share/icons/hicolor/scalable/apps
means most desktops will have one icon that works for all sizes.
So we can install an icon here:
~/.local/share/icons/hicolor/48x48/apps/example-app.png
or here:
~/.local/share/icons/hicolor/scalable/apps/example-app.svg
Then simply refer to the iconstring as example-app like this:
Icon=example-app
and the launcher process will be able to find the icon.
This is not really a relative path,
but it solves the problem of having to use an absolute path,
and it won't break if the desktop file is moved to a different location.
The same applies to the Exec key,
except it's executables somewhere in $PATH
instead of images in icon folders.
Epilogue: prior discussion and links.
It should be noted that support for relative paths to icons
has been discussed on the FreeDesktop mailing list
at least as early as September 2008:
Magnus Bergmark magnus.bergmark at gmail.com
Tue Sep 23 01:01:32 PDT 2008
[ . . . ]
I propose that we allow the usage of relative paths in some way also.
Use-cases
I use a lot of .directory files to make directories containing a movie
have the movie poster as the icon. This behaviour could apply to any form of
media, like comic books, music (album art) and photos.
A vendor might want to bundle an icon to a piece of software they're
distributing to go with a .desktop file which are not to go in the
desktop menu and therefore are still located in the application directory.
https://lists.freedesktop.org/archives/xdg/2008-September/009940.html
The only counterargument I was able to find
to this proposal is here:
A .desktop file
that is not intended to go into a standard applications directory is
almost entirely useless. Perhaps you should look at some of the
software bundle proposals and implementations, and work with using
those, instead. Another option is the xdg utils scripts, to install
the .desktop file and icons in the appropriate places. I can only
presume that your uninstalled application also intends to not follow
the Icon Theme and Icon Naming specifications either. And I don't see
setting the directory's icon as useful really. Setting an icon for the
actual executable would be much more useful, though elf binaries do
not have resources like win32 binaries do.
https://lists.freedesktop.org/archives/xdg/2008-September/009962.html
Related questions:
Relevant links:
