Making a desktop launcher for AppImage programs on elementary OS
AppImage is a popular format for distributing Linux applications as single self-contained files. On elementary OS, where the AppCenter focuses on a curated set of native packages, AppImages fill a useful gap for software that isn't packaged for the platform. The catch is that they aren't installed in the traditional sense, so the dock and the Applications menu don't know about them until you create a small helper file.
elementary OS is built on the Pantheon desktop environment, which follows the Freedesktop specifications shared with GNOME, KDE, and other modern Linux desktops. A launcher on this platform is just a small text file ending in .desktop that describes the program, points to its icon, and includes the command to launch it. Once you understand the structure, you can produce one for any AppImage you download, and the same knowledge transfers to other Linux distributions.
This guide is written with an Australian audience in mind, whether you're a hobbyist tinkering on a laptop in Brisbane, a freelancer running a small studio in Adelaide, or a sysadmin at a Perth-based consultancy looking after a fleet of workstations. The instructions assume elementary OS 7 (Horus) or 8 (Circe), but the underlying approach applies to any recent release of the distribution.
Before diving in, it's worth taking a snapshot of your system. Tools like https://elementarynow.com/applications/timeshift make it simple to roll back if a misplaced launcher or stray file clutters your home directory. With that safety net in place, the rest is straightforward.
What an AppImage actually is
AppImages bundle an application together with its libraries and dependencies into one executable file. Unlike a .deb package or a Flatpak, they don't get extracted into the filesystem in the conventional sense — you simply make the file executable and run it. This is attractive for developers who want a single artifact that runs across many Linux distributions without rebuilding.
For users, the trade-off is that AppImages don't integrate with the desktop by default. There's no automatic menu entry, no installed icon, and no obvious place for the system to discover them. On a fresh elementary OS install, double-clicking an AppImage in Files will often open it inside the sandboxing sandbox with limited permissions, which is great for safety but inconvenient for an app you actually want to use day to day.
The fix is to create a proper launcher. Once that's in place, the program behaves like any other installed application — searchable from the Applications menu, pinnable to the dock, and launched with the right environment variables automatically. The whole process takes a few minutes the first time and seconds thereafter.
Preparing the AppImage file
Start by placing the AppImage somewhere stable. A common habit among Australian Linux users is to keep downloads scattered between folders like ~/Downloads, ~/Software, or even a dedicated SSD mounted under /mnt. For a launcher that survives reboots and disk cleanup, the safest location is ~/.local/bin or ~/Applications, both of which are reserved for user-managed binaries and stay out of the way of system updates.
Move the file there, then make it executable. Open a terminal, navigate to the folder, and run chmod +x your-app.AppImage. From a Files user, say in Canberra, you'd right-click the file, choose Properties, tick the "Executable" box, and apply the change. Either approach works; the terminal is just faster once you're comfortable with it.
It also helps to rename the file to something predictable. If the original is Kdenlive-23.04.0-x86_64.AppImage, shorten it to kdenlive.AppImage. The shorter name will appear in your launcher file, in your dock tooltip, and in any error messages you need to debug later.
Writing a .desktop launcher by hand
A desktop launcher is a plain text file with a specific structure. Create a new file in ~/.local/share/applications/ called something like kdenlive.desktop. The filename must end in .desktop and must match the entry name inside the file.
The minimum content looks like this:
[Desktop Entry]
Type=Application
Name=Kdenlive
Exec=/home/yourusername/Applications/kdenlive.AppImage
Icon=/home/yourusername/Applications/kdenlive.png
Categories=AudioVideo;Video;
Terminal=false
The Exec line points to the full path of your AppImage. The Icon line points to a PNG or SVG file. If you don't have a dedicated icon, omit the line entirely and the system will use a generic placeholder, or you can download one from the application's website and save it alongside the AppImage.
The Categories field controls where the entry shows up in the Applications menu. elementary OS groups applications into Audio & Video, Graphics, Office, and similar buckets, so picking the right one improves discoverability. Save the file, and within a few seconds the launcher should appear in your menu.
Letting a graphical tool do the work
If editing text files feels like overkill, the elementary OS community has produced several small utilities that wrap this process in a friendly interface. AppImageLauncher is the most popular — install it, run it, and it offers to integrate any AppImage it finds in your home directory with a single click.
After installation, right-clicking an AppImage in Files gives you an "Integrate and run" option. Behind the scenes, the tool creates the .desktop file, moves the AppImage into a consistent location, and refreshes the menu. It's the path most people take when they want to get back to actually using the tool rather than configuring it.
For users who only need the occasional launcher, the manual approach is faster than installing extra software. For users who manage many AppImages — a common situation for folks in Adelaide's design agencies or Melbourne's indie game studios — the graphical tool pays for itself the third time you use it.
Placing the launcher where elementary OS will see it
elementary OS reads launcher files from a handful of standard locations. The two that matter most are /usr/share/applications/ for system-wide entries that require root, and ~/.local/share/applications/ for per-user entries that don't. For personal AppImages, the user-level folder is almost always the right choice.
It's writable without sudo, it survives system updates, and it keeps your customisations separate from the base system. If you're setting up a launcher for every workstation in a Brisbane office, you might prefer the system-wide location, but for a single machine the user folder is cleaner and easier to back up.
After saving the file, log out and back in, or run update-desktop-database ~/.local/share/applications/ in a terminal. The menu will refresh and your new entry will appear alongside the others. From there, you can drag it to the dock for one-click access.
Fixing the usual suspects
When a launcher refuses to behave, the cause is almost always one of a few things. The most common is a wrong path in the Exec line — if you moved the AppImage after creating the launcher, the path won't match and the menu entry will silently fail. Open the .desktop file in a text editor and double-check the full path against where the file actually lives.
Another frequent issue is the AppImage not being executable. The launcher will appear in the menu, but clicking it produces nothing. Run ls -l /path/to/app.AppImage to confirm the executable bit is set. If you've copied the AppImage from an external drive formatted as NTFS or exFAT, the permissions often don't survive the transfer — copying it again to a Linux-native filesystem like ext4 or btrfs fixes this.
Icons are the third classic headache. If the icon path in your launcher is wrong, the entry still works but shows a generic placeholder. Save a proper icon into the same folder as the AppImage and update the Icon= line to match. PNG files at 256×256 or 512×512 work well with Pantheon's scaling.
Sandboxing can also interfere with AppImages that expect to write to certain paths. If an app refuses to save files or access network resources, try running it once from the terminal outside the sandbox. The error message will tell you exactly what's being blocked.
Keeping your launchers healthy
AppImages don't auto-update the way Flatpaks do, so it's worth revisiting your launchers every few months. New releases come out, the old AppImage becomes obsolete, and you end up with a menu full of stale entries. A small habit of pruning your ~/Applications folder once a quarter keeps things tidy.
If you maintain a launcher for a tool you use at work, consider keeping a copy of the .desktop file in a dotfiles repository. A Sydney-based IT contractor I know syncs his launcher folder across all his client machines using a private Git repo, which means a fresh elementary OS install becomes usable in under five minutes. The same trick works for personal setups if you ever reinstall or buy a new laptop.
For users concerned about the Privacy Act 1988 and the Notifiable Data Breaches scheme — Australian legislation that affects how businesses handle personal information — AppImages are worth a moment of thought. Because they're not sandboxed by default, an AppImage has the same access to your files as any other program you run. Only download AppImages from sources you trust, and verify checksums when the developer provides them.
Take the AppImage you use most often — whether that's Kdenlive, OBS Studio, or a less common tool — and turn it into a proper launcher today. Place the file in ~/.local/share/applications/, log out and back in, and pin the new entry to your dock so it sits within easy reach whenever you need it.
