I am working with Obsidian (the markdown editor). Recently, we have revamped our snap taking advantage of the new core24 pipeline of electron-builder. This has solved some long standing issues, however we have noticed new ones.
This thread is specifically about snaps and their integration with desktop environments under Wayland (which is enabled by default since circa Electron 38).
The setup
Obsidian uses electron, and build its packages with electron-builder including the snap (classic confinement).
desktopName, Wayland’s app_id are set tomd.obsidian.Obsidian(following the convention of using FQDN), StartupWMClass is also set to md.obsidian.Obsidian within the .desktop file.
The snap produced by electron-builder (v26, syncDesktopName=true) has a template meta/gui/md.obsidian.Obsidian.desktop within the .snap.
When the snap is installed, it (snapd?) creates /var/lib/snapd/desktop/applications/obsidian_md.obsidian.Obsidian.desktop (from meta/gui/md.obsidian.Obsidian.desktop).
The problem (Generic Wayland icon)
The observed behavior when running Obsidian on (K)Ubuntu 26.04:
GNOME: Icon in taskbar is generic wayland icon, icon in application switcher (alt-tab) is generic wayland
KDE: Icon in taskbar in correct, icon in application frame and in the application switcher (alt-tab) is generic Wayland (See this KDE-BR-466599)
XFCE: users also report problems, but I haven’t tested.
What window managers expect
If I manually rename /var/lib/snapd/desktop/applications/obsidian_md.obsidian.Obsidian.desktop to obsidian_obsidian.desktop Gnome works better, but KDE still has the same problems.
If I manually rename /var/lib/snapd/desktop/applications/obsidian_md.obsidian.Obsidian.desktop to md.obsidian.Obsidian.desktopeverything works everywhere.
Why the problem specifically with Snaps
It seems that snapd creates .desktop files in /var/lib/snapd/desktop/applications/ using the pattern {snapname}-{originaldesktopfile}.desktop.
All other package formats we support (deb, flatpak) install a md.obsidian.Obsidian.desktop and that works everywhere.
The Solution?
I hope my understanding of the problem is correct. I am not sure what the solution to this problem is. Specifically, I am not sure:
if electron-builder should do something special while building the snap
OR
if this is something that snapd should handle with some manipulation at installation time
OR
if desktop environments have to become “snap” aware in their search for a match, that is the DE also searches for obsidian-md.obsidian.Obsidian.desktop.
Not just obsidian
This issue are not limited to Obsidian, in fact I did find some hits online of people complaining about the issues about in various apps including in this forum (see 1).
Can you confirm this is still occurring? I’ve tried in a 26.04.1 Gnome Live CD environment, both aspects work fine.
The ‘technically’ TM correct way to fix this is to rename the .desktop file as you’ve identified, however, there’s a secondary way to fix this at the Wayland protocol level, which KDE then supports in its compositor. https://wayland.app/protocols/xdg-toplevel-icon-v1 - This is available in Electron 40 and works automatically, whereas Wayland by default is Electron 38 (so I’m assuming you’re using version 38/39).
So regarding solutions
From the perspective on the desktop environments, they would rather snapd modify the .desktop file names appropriately (I’m vaguely aware the desktop-file-ids attribute exists and may help here, but not understanding how it’s intended to be used, I’m unsure if it gives enough control to do so, possibly requiring overriding the Wayland app ID for the snap build).
StartupWMClass= should still work fine on all reasonable desktop environments, with the value you already have in revision 68, so would be worth confirming these errors still exist on Gnome (separately, XFCE is interesting because all the real world experience I have to hand suggests that on X11 this is rarely a problem, since X11 apps can set these icons at a protocol level for years already, even if StartupWMClass= is wrong and the .desktop file is misnamed).
The KDE quirks must be fixed at the Wayland protocol level or by renaming the desktop file, but Electron 40 should handle the protocol level for you.
N.B this is comparing against a similar Electron app that’s gone through both recent Wayland Electron releases & Electron Builder 26 recently, however this one doesn’t use the full Electron Builder pipeline to produce the .snap file itself.
In our latest SNAP, we are manually creating obsidian.desktopwithin the Snap (in place of md.obsidian.Obsidian.desktop we had previously).
When it is installed, snapd generates obsidian_obsidian.desktop from it. As I said in my first message obsidian_obsidian.desktop works on GNOME but still doesn’t work on KDE (application switcher and window frame are wrong).
We got there by guesswork and trial and error and we are sticking to it because it is less bad than what we had previously. However, it isn’t clear to me what the right thing to do and who should fix what.
The right thing to do depends upon perspective, changing the .desktop name is a valid fix, and it’s also valid for snapd to not want to allow for it in the default case, I’d let someone else comment on desktop-file-ids and whether it can help there.
In my opinion, having this at a protocol level rather than arbitrarily deciding file names are important is a better fix at a design level. I like the KDE support at the protocol level best. So the solutions aren’t necessarily all at the .desktop file handling level for options like making desktops “snap aware”.
The KDE issue should be fixed in Electron 40 and above, are you using it?
"This is a frustrating issue caused by how snapd renames .desktop files with a prefix, breaking the app_id match in Wayland. Expecting every DE to add workarounds isn’t practical, so snapd itself should probably preserve original desktop filenames or handle aliases better. Thanks for tracking this down!