Please stop using absolute paths for desktop files.

[envygeeks]

• I have searched open and closed issues for duplicates

---

Bug description

Signal Desktop uses an absolute path for it's desktop file located at /usr/share/applications/signal-desktop.desktop, which is contrary to what you should be doing to maintain an extensible and customizable system. This prevents people from wrapping on-top of Signal to prefer pre-tasks or setup.

Steps to reproduce

• Install Signal-Desktop on Linux

Screenshots

[Desktop Entry]
Name=Signal
Comment=Private messaging from your desktop
Exec="/opt/Signal/signal-desktop" %U
Terminal=false
Type=Application
Icon=signal-desktop
StartupWMClass=Signal
Categories=Network;

Platform info

Browser: Non-relevant.
Operating System: Ubuntu 16.04, 17.10
Signal version: Non-Relevant.

---

On Linux it is preferred that you use a non-absolute searchable binary-name, so that the system can decide based on the users preference what file to use to launch. Using an absolute path prevents me from creating a wrapper that forces Signal into a slice, or onto a Docker image on the fly or anything that would require me to create a system-wide wrapper.

On our systems it would be desireable to be able to wrap Signal to prevent it from using resources we don't want it to use. We can force Systemd to reclaim memory we don't want Signal to have. Lets face it, you are using JavaScript on the desktop, inside of a Chrome window, using v8, and while we accept this is the easiest way for you to ship us a cross-platform application, we do not accept the amount of resources that Chrome opportunistically claims in excess of reasonable.

[envygeeks]

I understand this might complicate matters for Signal, but it's acceptable for even /opt/<namespace> apps to place a binary in /usr/bin that points to your binary in /opt. The same way that Google-Chrome does (not that I use Google's version of Chrome.)

[envygeeks]

/usr/bin/signal-desktop

#!/bin/bash
set -e

exec /opt/Signal/signal-desktop "$@"

[envygeeks]

[Desktop Entry]
Name=Signal
Comment=Private messaging from your desktop
Exec=signal-desktop %U
Terminal=false
Type=Application
Icon=signal-desktop
StartupWMClass=Signal
Categories=Network;

[tribut]

The package already creates a symlink from /usr/local/bin/signal-desktop to /opt/Signal/signal-desktop, so a wrapper should not be needed.

[PMaynard]

On as side note from the initial issue topic.

I don't believe /usr/local/bin is the correct location to store a symlink. See here for what should go in /usr/bin, and here for what should go in /usr/local/bin.

I think a better place for the symlink is in /usr/bin over /usr/local/bin. As some programs might not identify signal-desktop as being installed. (e.g. How I ended up here)

[chiraag-nataraj]

Please, can we switch to installing the symlink in /usr/bin? Programs installed by the system (e.g. through a package) should be installed in /usr/bin, with /usr/local/bin being reserved for self-compiled programs.