GNOME AppImage's have issues with displaying icons across multiple contexts. Other Desktop Environments, e.g. KDE Plasma, don't have any issues with our AppImage icons. A fair amount of investigation went into debugging the behavior on Ubuntu 24.04 GNOME (see: #353 (comment)).
I'm dropping the results of the investigation with Claude. I'd anticipate this context will be good to feed into a future prompt if we want to go down this rabbit hole or if a newer version of Ubuntu/GNOME unlocks a viable solution
## Summary: There's No Reliable Universal Fix
The research confirms what we found in our testing. The issue breaks down into two separate problems with different (non-)solutions:
### 1. File Manager Icon (AppImage file itself in Nautilus)
**Status: Essentially unfixable on GNOME**
The xapp-thumbnailers project from Linux Mint claims compatibility with Nautilus and includes an AppImage thumbnailer that "produces thumbnails for AppImage files." However:
- It's only available in Linux Mint's PPA, not Ubuntu repos
- No confirmed user reports of it actually working on Ubuntu GNOME with Nautilus
- Would require adding Mint's PPA or building from source
- Even if it works, it only generates thumbnails for the file itself, not the running app icon
### 2. Taskbar/Dock Icon (when app is running)
**Status: Works for SOME apps, fails for others - no pattern**
The StartupWMClass fix is the standard approach, and users report it works for apps like Transmission, VirtualBox, Clementine, and Signal. But the same thread shows failures:
- "Worked for me on Clementine, but not on the icons on the desktop that are appimage files FreeCAD and Cura"
- "Not working for me. Slickedit 2018 has a class of 'Vs_exe' but even with that set in the .desktop file, I still get the generic icons. I didn't have this problem in Ubuntu 22."
- "I have the same problem with Skype...This is a snap package but other snap packages work fine...The difference is 'Skype' uses 'XWayland'"
### Why It Fails for ecash-app (and similar Flutter/Electron apps)
In our previous testing, `xprop WM_CLASS` and `wmctrl -lx` returned nothing. This happens when:
1. The app runs under Wayland without proper XWayland integration
2. The app's toolkit (Flutter in ecash-app's case) doesn't properly set WM_CLASS
3. The WM_CLASS is set to something like `AppRun.wrapped` which changes per session
### What Tools Like Gear Lever Actually Do
The Warp terminal issue confirms this affects multiple popular apps: "Running it seems to go fine, but the app icon is a generic gear icon: in task bar, in file viewer, when (alt-tab) switching to other windows"
Tools like Gear Lever and AppImageLauncher attempt to extract and register icons, but they can't fix the fundamental WM_CLASS matching problem if the app doesn't report one properly.
The honest answer is: **this is a known, unresolved GNOME limitation with no reliable fix for AppImages**. The icon embedding in ecash-app is correct. Whether the dock icon works depends on factors outside your control (the app's WM_CLASS reporting, Wayland vs XWayland, GNOME's strict matching requirements). KDE Plasma is simply more forgiving. There's nothing actionable on the packaging side.
GNOME AppImage's have issues with displaying icons across multiple contexts. Other Desktop Environments, e.g. KDE Plasma, don't have any issues with our AppImage icons. A fair amount of investigation went into debugging the behavior on Ubuntu 24.04 GNOME (see: #353 (comment)).
I'm dropping the results of the investigation with Claude. I'd anticipate this context will be good to feed into a future prompt if we want to go down this rabbit hole or if a newer version of Ubuntu/GNOME unlocks a viable solution