0

I have a .desktop file like this that I've used to distribute an internal tool to non-technical people to install on my ubuntu systems. The tool is delivered on CD/DVD. On 18.04, they'd insert the CD/DVD, double click the launcher icon, and the installer scripts would be launched (which then installs the tool).

I can't get this to work on 22.04. After mounting the media, instead of a "launcher" icon appearing in nautulus ("Files"), I see the mytool.desktop file. Double-clicking that opens the .desktop file in a text editor.

The .desktop file as 555 permissions, and if I right-click to look at properties, the "Allow executing file as a program" box is checked.

Is this use case no longer supported? Is there something else I'm missing? I've seen the posts suggesting moving the desktop file to specific folders on the filesystem, but my use case is to give users an easy way to launch an installer.

Here a very slightly sanitized version of my .desktop file. desktop-file-validate reports no errors.

[Desktop Entry]
Version=1.4
Name=Launch My Tool
Comment=Launch My Tool
Exec="/bin/sh -c /path/to/file/on/disk.sh"
Terminal=false
Type=Application
Icon=application-x-executable

1 Answer 1

2

Indeed, as you suspected yourself, this user case is not anymore supported. Since a few versions, .desktop files in the file manager do not anymore present themselves as launchers, but as plain text files that open in a text editor. In fact, the whole concept of just executing any file by double-clicking has been deprecated in the Gnome Desktop (with nautilus). For media, some standard installed applications can be autostarted on insertion, (e.g. you media player on inserting an audio CD), but you cannot automatically run anything from an inserted medium.

This is inspired by safety concerns. It eliminates that users inadvertently run software, which could do damage at that moment, and even could be malicious. The idea is that software should be run in a standard way (through icons or through typing the name of an executable properly installed in the search PATH, although it remains possible to run an executable anywhere by typing the full path (including ./... for an executable in the current directory). The latter, however, will much less likely be done by accident.

Obviously, in your use case, that renders deployment of a tool from an inserted drive (somewhat) less user friendly.

The most user friendly approach probably would be to package your software as a .deb file. On double clicking it, the software center will start to prompt for installation. This also would cause your tool to be integrated in the APT system, so it can easily be removed.

You obviously can also work with your installation script, but you will need to provide instructions in a few steps on how to launch it.

2
  • Thanks @vanadium! The installer in this case is an executable, kicked off by a script that launches a GUI prompt for the admin password. The actual installer does install debian packages (a handful, actually), along with creating uninstall shortcuts and a few other things. I'll explore some other ways to do this. Do you happen to know if there are any issues/PRs where there'd be discussion about this functionality being deprecated? Or where I'd look for that?
    – ndtrek07
    Oct 12, 2022 at 17:22
  • The Gnome issues site gitlab.gnome.org/groups/GNOME/-/issues is where a lot if discussions happen at the time of raising an issue, but probably there are other places where the blueprint and broad design decisions are developed and made
    – vanadium
    Oct 13, 2022 at 9:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .