search

zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
https://zed.dev
Other
47.7k stars 2.79k forks source link

Linux .desktop file improvements #12707

Closed jansol closed 2 months ago

jansol commented 3 months ago

Check for existing issues

Describe the feature

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 commented 3 months ago

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

jansol commented 3 months ago

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

ReillyBrogan commented 3 months ago

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 commented 3 months ago

Ooh, thanks for the clarification @ReillyBrogan !