[Bug]: Linux Wayland (GNOME, Noctalia) overview shows a placeholder icon after AppImage reinstall #10894

Activity

1. bczaplicki-gd commented on Sep 9, 2026

   

   bczaplicki-gd

   on Sep 9, 2026

   More actions

   Also affected on Ubuntu 24.04.4 LTS, GNOME Shell 46.0, Wayland, using AppImageLauncher 3.0.0-beta-2.

   Observed with 0.0.41-nightly.20260909.1439; inspection of the installed 0.0.41-nightly.20260909.1461 AppImage confirms the same startup code remains present. This affects desktop integration beyond the cosmetic overview icon: the running app had no proper icon and could not be pinned to the GNOME dock normally.

   Reproduction / observations

   1. Integrate the nightly AppImage with AppImageLauncher and launch it on GNOME Wayland.
   2. Observe the running application's icon and try to add it to favorites.
   3. Inspect ~/.local/share/applications/com.t3tools.T3Code.desktop: T3 Code generates a URL-handler entry with NoDisplay=true and no Icon=.

   AppImageLauncher separately generated a visible desktop entry containing a valid installed icon and StartupWMClass=t3code. The icon files were already present in the user's hicolor theme on this machine, so this instance does not depend on missing packaged icon installation or Noctalia's lowercase lookup.

   In build 1461's bundled apps/desktop/dist-electron/main.cjs, renderUrlHandlerDesktopEntry() still emits the hidden, iconless entry. The pre-ready startup code unconditionally writes that entry, then calls electron.app.setDesktopName(linux.linuxDesktopEntryName) and sets the window class to t3code. This appears to associate the window with the hidden URL handler instead of the visible AppImageLauncher entry. The URL-handler registration service also writes this file when its content differs, so simply adding an icon or removing NoDisplay is not a durable repair.

   Workaround and update consequences

   Locally, we made the canonical entry visible, added an installed icon and StartupWMClass=t3code, and made the file read-only to prevent startup overwrites. This is only a workaround: after integrating 1461, the repaired/pinned entry still pointed at 1439, while AppImageLauncher had entries for both builds. That left three similar application choices. We manually updated the canonical entry to 1461 and hid the duplicates. The extra visible entry was a consequence of this workaround, not a claim that an untouched install creates three visible entries by itself.

   Expected behavior: a visible application entry with a resolvable icon, working dock pinning, and a consistent window identity. Startup URL-handler registration should preserve that entry, or use a separate handler identity without making it the running window's desktop identity.

   Report prepared with AI assistance from local desktop-entry and bundled-code inspection; build 1461 was not freshly retested with the workaround removed.
2. mwolson commented on Sep 9, 2026

   

   mwolson

   on Sep 9, 2026

   ContributorAuthor

   More actions

   Thanks for the detailed report. You're right that GNOME pinning needs more than installing icon files. I've expanded #10895 linux-wayland-desktop-icon to cover launcher matching too.

   GNOME checks StartupWMClass before the desktop filename. The visible launcher's t3code value didn't match the window's existing com.t3tools.T3Code identity, so GNOME selected the hidden URL handler and rejected it for favorites. The fix makes the visible launcher match, while keeping the handler hidden and preserving capture bindings. It doesn't add another visible launcher.

   I reproduced the failure and verified matching, pinning, and relaunch using generated desktop-entry fixtures with GNOME 50.4/Electron 44.1.0 on Wayland and Xwayland. I haven't tested your exact GNOME 46/AppImageLauncher setup.

   Existing AppImageLauncher entries need re-integration to receive the corrected metadata. Old pins and previous-build entries aren't migrated automatically. Once a build includes this change, a retest without the read-only canonical-entry workaround would help confirm the remaining integration/update behavior.
3. mwolson

   changed the title [-][Bug]: Linux Wayland overview shows a generic icon after AppImage reinstall[/-] [+][Bug]: Linux Wayland (GNOME, Noctalia) overview shows a placeholder icon after AppImage reinstall[/+] on Sep 10, 2026
4. OffCrazyFreak commented on Sep 17, 2026

   

   OffCrazyFreak

   on Sep 17, 2026

   More actions

   Adding a datapoint from X11, since the reports so far are all Wayland: same thing on Linux Mint 22.3, Cinnamon 6.6.9, X11, with the 0.0.42 AppImage. The window list shows a generic icon for the running T3 Code window. 0.0.40 was fine here.

   I dug into why, in case it helps with #10895:

   • feat(desktop): add cross-platform window capture #8103 (first in 0.0.42) calls Electron.app.setDesktopName("com.t3tools.T3Code.desktop") in DesktopPreReadyPlatform.ts and writes that hidden entry (NoDisplay=true, no Icon=) on every launch.
   • Since Electron 43 (fix: set XDG app ID and WM_CLASS based on normalized app name electron/electron#51424, "set XDG app ID and WM_CLASS based on normalized app name") the X11 WM_CLASS is derived from the desktop name as well, not from productName. So the commandLine.appendSwitch("class", "t3code") right next to it no longer affects the main window. xprop on 0.0.42 shows WM_CLASS = "com.t3tools.t3code", "com.t3tools.T3Code".
   • Cinnamon (same heuristics as GNOME Shell) tries StartupWMClass first and then matches WM_CLASS against desktop file ids, so it lands on the hidden iconless entry. The window sets no _NET_WM_ICON, so there is no pixmap fallback either. On 0.0.40 nothing matched, and the shell could still link the first window through startup notification, which is why it looked fine until now.

   Confirmed as a working local fix by adding StartupWMClass=com.t3tools.T3Code to my own visible launcher, which is what #10895 does for the packaged one, so that PR should cover X11 too. Happy to test a build if that helps.
5. eduardozf commented on Sep 23, 2026

   

   eduardozf

   on Sep 23, 2026

   More actions

   I reproduced this on Pop!_OS 24.04 with COSMIC/Wayland and the 0.0.43 nightly AppImage. T3 Code showed as a cog in the top panel. The AppImage contained the icon, but the generated com.t3tools.T3Code.desktop entry had no Icon= line.

   I copied the bundled icon into ~/.local/share/icons/hicolor, added Icon=t3code to that entry, and made it read-only temporarily because T3 Code rewrites it on launch. The cog remained until I restarted cosmic-app-list; I checked the panel again and the T3 icon appeared. It may help to include the icon when generating the entry. On COSMIC, testing that change may also require an applet restart because it cached the old entry.