Wayland incompatible name of .desktop file, should be GitHub Desktop.desktop

[mkurz]

The problem

You have the same problem like Signal and other Electron applications have when running under Wayland. The app icon is incorrect. See the attached screenshot of Signal, but it applies to GitHub Desktop as well.

Currently, Wayland expects the desktop file name to be the same as the "app id". You can find out that id by running WAYLAND_DEBUG=1 github-desktop, you will see that it is GitHub Desktop.

So if you under Wayland, just test this by renaming the desktop file to GitHub Desktop.desktop and start the app again. You will see that now the icon is correct.

I wrote a lengthy comment in the signal issue tracker too already with more details, take a look, there are also other links which provide even more information (the ones that point to https://aur.archlinux.org/ ...)

• Wrong name of .desktop file signalapp/Signal-Desktop#6239

Caution

Be aware that changing the desktop file name might break the MIME Type handling (in your case when you authorize users in the browser on GitHub and then expect GitHub Desktop to take over from there). Not sure though, but you should test that.

Release version

3.4.8 Linux RC1

Operating system

Arch Linux with KDE Plasma 6.2 under Wayland

Steps to reproduce the behavior

No response

Log files

No response

Screenshots

From Signal, but also applies to GitHub Desktop:

Additional context

No response

[Richardk2n]

Works for me with the existing name.
Do you have ELECTRON_OZONE_PLATFORM_HINT set to something?

[mkurz]

Works for me with the existing name.

Probably because you run it with XWayland?

Do you have ELECTRON_OZONE_PLATFORM_HINT set to something?

Yes. To make sure my electron apps run native under Wayland.

$ env | grep -i electron
ELECTRON_OZONE_PLATFORM_HINT=wayland

[Richardk2n]

I have it set to auto and all my electron apps run using wayland (except for discord, which I force to use XWayland for screen-sharing). Complete with the missing icon you call correct for some reason. There was no need to rename any .desktop files.

[mkurz]

Sorry, I think there is a misunderstanding. Do you see the yellow "W" icon (which is not "correct") or do you see the GitHub Desktop icon (which you should).

[Richardk2n]

Sorry, there most definitely is a misunderstanding. I understood your issue as you using the icon as an indicator of whether the application is using Wayland or not, which would be understandable, given the Wayland people took quite some time to come up with a protocol to set icons.

Can you link documentation, where the name of the .desktop file is stated to be required in this way? I did not know about any such requirement and just assumed all the apps to not yet be updated to use the new protocol. Is it universal or only for some implementations?

[mkurz]

There are some interesting comments in the Electron code:

• https://github.com/electron/electron/blob/v33.3.0/shell/browser/native_window_views.cc#L303-L304
  • ➡️ https://github.com/electron/electron/blob/v33.3.0/shell/common/platform_util.h#L64-L66
    • ➡️https://github.com/electron/electron/blob/v33.3.0/shell/common/platform_util_linux.cc#L426-L438
      (here it make sure the desktop file name matches ☝️)
      • ➡️https://github.com/electron/electron/blob/v33.3.0/shell/browser/api/electron_api_app.cc#L930-L935
• This pull request gives more details as well: fix: set Wayland application ID electron/electron#34855

What you can do also, run:

$ qdbus org.kde.KWin /KWin queryWindowInfo

and click on the app windows, you should see desktopFile, which is the name of the GitHub Desktop[.desktop] file that is expected.

Also Gnome recommends that the desktop file name should match the app_id (or WM_CLASS in X), please see the gnome wiki: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased#The_Application_ID:

When using the GtkApplication API it is important to choose a unique application identifier. This identifier is the preferred mechanism used to match the application's own name on the session bus, as well as the .desktop file of the application itself. This is especially important when using GNOME Shell as a Wayland display server, as opposed to an X11 compositor.
When creating a new GtkApplication instance, ensure that your application identifier is the same as the name of your .desktop file, minus the extension:
...
Note: it's recommended that you use the same identifier for your application id, .desktop file, .service file, and application icon. This allows the Shell to match all your assets to the application, and prepares your application for sandboxing.
...
To ensure the GNOME 3 Shell will track your application, you can also set the WM_CLASS X window property to be the same as your application's .desktop file name, without the .desktop extension (the desktop file should be lower-case).
The easiest way to achieve this is to have your application's process name match the .desktop file name, and ensure you use g_option_context_parse.
...

JetBrains is working on native Wayland support for IntelliJ (=for Java basically) and they hit the same problem:

• https://youtrack.jetbrains.com/issue/TBX-12132/Enable-app-icon-association-on-Wayland-desktops
• https://youtrack.jetbrains.com/issue/JBR-6547/WLToolkit-no-app-icon-in-GNOME
• ➡️ openjdk/wakefield@05545a5

For the long term: Recently the Wayland "XDG toplevel icon" showed up, which maybe make this "hacks" unnecessary:

• https://wayland.app/protocols/xdg-toplevel-icon-v1
• https://invent.kde.org/plasma/kwin/-/merge_requests/5680
• testing wayland JetBrains/JetBrainsRuntime#242 (comment)