Repository navigation
Use desktopName to create the .desktop file for Linux packages #4313
Description
Pre-flight checklist
- I have read the contribution documentation for this project.
- I agree to follow the code of conduct that this project uses.
- I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Problem description
Electron uses the desktopName property in package.json to determine the XDG App ID: https://www.electronjs.org/docs/latest/api/app#appsetdesktopnamename-linux. This value is supposed to match the base name of the .desktop file installed for the app, e.g.
- XDG app ID:
com.company.MyApp - File:
/usr/share/applications/com.company.MyApp.desktop
If the XDG App ID doesn't match the filename, desktop environments on Wayland may not be able be able to match icons, keyboard shortcuts, and other portals.
Proposed solution
If desktopName is set in package.json, forge should use it as the basename for the .desktop file it creates.
Ideally, Forge would also show a warning if the value is not set when building Linux targets. A matching App ID is becoming more important in modern desktop environments. Ideally, it should be a FQDN e.g. com.company.MyApp.
Alternatives considered
Forge will currently produce a .desktop file based on the executable name or product name even if desktopName is set. These are not really suitable options especially given the move toward FQDNs.
Additional information
Related to electron/electron#52222.
Activity
SpacingBat3 commentedon Jul 19, 2026
I don't think Forge should issue a warning, given
desktopNameis not a single normalized method that everyone might use (outside ofapp.setDesktopNameI believe there's alsoStartupWMClassin.desktopyou might use to configure its behaviour). And……with in practice my desktop showing me many apps are not following the name convention for desktop file names that FreeDesktop seem to define in spec, I also feel like this contradicts with how software is being distributed, and I think taking more relaxed than restricted approach on handling App ID would be appropriate, at the same time with how elastic Forge is, an opinionated plugin to validate this across some preferred norms could be done, even outside Forge if Forge would have no interest at maintaining something like this (+ I believe there were similar concepts for "good practices in Electron" also outside Forge in the past that didn't quite worked out). But these are only my thoughts.
With that said, I'm glad I've noticed this issue, since myself I am in favour of implementing this into my makers (present/future ones, given how ReForged has current type hierarchy) and once I try it out there, I might also work on this for Forge and present it as PR unless someone will approach this before me.