VS Codium for Wayland does not show the right titlebar icon
Describe the bug When opening VSCodium, the application does not set the correct icon for the window under Wayland sessions. Instead it uses the default Wayland icon.
Please confirm that this problem is VSCodium-specific
- [x] This bug doesn't happen if I use Microsoft's Visual Studio Code. It only happens in VSCodium.
Please confirm that the issue/resolution isn't already documented
- [x] I checked the Docs page and the Troubleshooting page and my issue is not mentioned there.
To Reproduce Steps to reproduce the behavior:
- Start a Wayland session (e.g., on GNOME or Sway).
- Launch VSCodium.
- Observe the titlebar/window icon displayed by Wayland.
Expected behavior The application should display the correct VSCodium icon in the titlebar/window as expected.
Screenshots
What it currently looks like (from vs codium):
What it should actually look like (from vs code):
Desktop (please complete the following information): OS: [Arch Linux] Architecture [x64] Version: 1.96.0 Commit: 138f619c86f1199955d53b4166bef66ef252935c Date: 2024-12-16T11:38:33.840Z Electron: 32.2.7 ElectronBuildId: undefined Chromium: 128.0.6613.186 Node.js: 20.18.1 V8: 12.8.374.38-electron.0 OS: Linux x64 6.12.4-arch1-1 App Manager: [yay] Sandboxed [N/A]
Additional context This issue does not occur under X11 sessions or when using Microsoft's Visual Studio Code. The issue seems specific to Wayland and VSCodium.
I encountered a similar issue in a pull request for SDR++ and was able to resolve it by explicitly setting the application ID for GLFW using the GLFW_WAYLAND_APP_ID window hint, which had to match the .desktop file. It might be worth investigating whether a similar approach can be applied to Electron (the framework used by VSCodium) to ensure that the correct application ID is set for Wayland sessions.
Related to #2127 and #1901
The icon is not correctly displayed on these versions:
-
cachyos/vscodium1.98.2.25072-1 -
aur/vscodium1.98.2.25072-1
The icon is correctly displayed on these versions:
-
aur/vscodium-bin1.98.2.25072-1
@ptr1337 could you take a look at this on the CachyOS repositories?
If it helps, a while back I made pull request that fixed this very issue in another project that was using GLFW by setting the hint for the window to: glfwWindowHintString(GLFW_WAYLAND_APP_ID, "<your app id>");. See: https://www.glfw.org/docs/3.3/group__window.html#ga7d9c8c62384b1e2821c4dc48952d2033
@ptr1337 could you take a look at this on the CachyOS repositories?
We only rebuild it from the AUR, since the AUR is also affected this appears to be an AUR packaging issue. Should be reported from there.
So should I forward and report this issue on the AUR package instead?
Not really since I'm a co-maintainer of the impacted AUR...
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment, and we'll keep it open. If you have any new additional information, please include it with your comment!
I think the issue is that https://github.com/microsoft/vscode/blob/50b5aa895467bcc17c91c9d2357f670969d4da3d/build/gulpfile.vscode.js#L260 ends up being codium.desktop but most distros seem to call the desktop file vscodium.desktop.
It would be nice to provide clear guidance on how the desktop file should be called and make sure that desktopName is set to the corresponding value.
I didn't try recompiling vscodium but changing the desktopName in the /usr/lib/vscodium/resources/app/package.json file does change the wayland app_id as expected.
The reason this works is that electron sets the wayland app_id based on the name of the desktop file: https://github.com/electron/electron/pull/34855 , https://github.com/electron/electron/blob/f62d7254c4c4c865e40da8056aee73644aa37bd7/lib/browser/init.ts#L130
And desktops often do some guessing to get the icon for running applications which includes opening <app_id>.desktop.
The icon is correctly displayed on these versions:
aur/vscodium-bin 1.98.2.25072-1
This is probably due to vscodium-bin-wayland.desktop containing StartupWMClass=codium which will also make most desktop guessing succeed but is more hacky due to needing 2 desktop files and misleading due to WMClass not actually being a thing on wayland.
aur/vscodium was probably working before https://github.com/microsoft/vscode/pull/231472 due to the same hack
Have you tried to change the window.titleBarStyle setting?
No, but why should that matter?