Skip to content

Fix hardcoded build paths in .desktop Exec and TryExec#127

Closed
Benibur wants to merge 1 commit intopkgforge-dev:mainfrom
Benibur:fix/desktop-exec-paths
Closed

Fix hardcoded build paths in .desktop Exec and TryExec#127
Benibur wants to merge 1 commit intopkgforge-dev:mainfrom
Benibur:fix/desktop-exec-paths

Conversation

@Benibur
Copy link

@Benibur Benibur commented Mar 7, 2026

Problem

The .desktop file embedded in the AppImage contains absolute paths from the CI build environment:

TryExec=/__w/ghostty-appimage/ghostty-appimage/ghostty-1.2.3/zig-out/bin/ghostty
Exec=/__w/ghostty-appimage/ghostty-appimage/ghostty-1.2.3/zig-out/bin/ghostty --gtk-single-instance=true

Desktop integration tools like appimaged extract this .desktop file and install it in ~/.local/share/applications/. Since the TryExec path doesn't exist on the user's system, GNOME Shell silently ignores the entry — the app never appears in the Dash/Overview search.

Fix

Replace absolute build paths with just the binary name ghostty in Exec and TryExec before bundling the AppImage. The AppImage runtime resolves the binary correctly.

Test

Before the fix, on Ubuntu 24.04 with GNOME Shell 46 + appimaged:

  • Ghostty AppImage does not appear in the application search
  • All other AppImages (Obsidian, Cursor, etc.) work fine

After manually creating a corrected .desktop file:

  • Ghostty appears and launches correctly from the Dash

The Ghostty build produces a .desktop file with absolute paths from the
build environment (e.g. /__w/ghostty-appimage/.../zig-out/bin/ghostty).
When desktop integration tools like appimaged extract this .desktop file
and install it on the user's system, TryExec fails because the path
doesn't exist, causing the entry to be silently ignored by GNOME Shell.

This replaces the absolute paths with just the binary name "ghostty",
which the AppImage runtime resolves correctly.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@psadi psadi requested a review from Samueru-sama March 10, 2026 02:37
@Samueru-sama
Copy link
Member

Hi, are you 100% appimaged was able to extract the desktop entry from this appimage?

Because appimaged does not support DWARFS, so I find it very unlikely that it was able to extract the desktop entry to begin with.

probonopd/go-appimage#343


In the README we recommend that you use AM or AppManager to manage appimages, those two support dwarfs and work without issue with the current appimage.

@psadi psadi closed this Mar 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants