Linux .desktop file improvements

[jansol]

Check for existing issues

• Completed

Describe the feature

• It would be nice if the Exec line accounted for passing files or URLs as arguments (so "Open With... > Zed" works properly, and for registering as a handler for https://zed.dev/channel/*-URLs). Looks like there is already some preparatory code for this but it's not being used.
• The file name of the .desktop file MUST match the wayland app id for it to get correctly associated with application windows.

EDIT: incorporated clarifications from @ReillyBrogan . StartupWMClass is not needed if the wayland app id (and therefore the file name) is identical to the WM_CLASS on X11. This is already the case, so no action is needed on that front.

[Moshyfawn]

I seem to remember the app_id proposal that was resolved in #10909. Does this satisfy your second point?

[jansol]

The 2nd point is about also having that app id stated in the .desktop file.

[ReillyBrogan]

It seems that you are a bit mistaken about how some of the .desktop FreeDesktop standards work.

The 2nd point is about also having that app id stated in the .desktop file.

The StartupWMClass is ONLY for the X11 window class (it even has WMClass in the name which is an X11-only concept). If the Wayland appId and the X11 resource class are different then the .desktop file should be named after the Wayland app_id and the StartupWMClass should be the X11 resource class to be compliant with the standards.

The name of the .desktop file MUST match the Wayland appId sans the .desktop suffix. If the Wayland appId is dev.zed.Zed then the .desktop filename MUST be dev.zed.Zed.desktop. This is an explicit part of the FreeDesktop standards.

If the Wayland appId and the X11 resource class are the same then the StartupWMClass can be omitted from the .desktop file.

You may be using GNOME desktop which adds the value of the StartupWMClass field to the search path for matching Wayland windows via their appId. This is technically non-compliant with the FreeDesktop standards but it does some windows matched that would otherwise not be due to packaging mistakes which is why they did it. No other window manager or compositor implements this behavior. Frankly it's a mistake that has harmed the ecosystem as people see apps that are correctly matched on GNOME that don't work on Plasma or other DEs/WMs who then think that there is an issue with the other DE/WM when they should be reporting it to the app developers/package maintainers. If it's fixed in a compliant way it works for ALL Wayland DEs/WMs, instead of only working on GNOME.

[jansol]

Ooh, thanks for the clarification @ReillyBrogan !