Add StartupWMClass to .Desktop file

[JGCarroll]

Fixes instances where the application does not have an icon in the dock and appears with a generic window icon.

---

Whilst this works for the Flutter based branches, it would be worth seeing what the legacy branches (E.G Ubuntu 22.04) configure as their WMClass, as if it doesn't match this may have the potential to cause more regression than fixes.

This PR comes from a user on the support Matrix who confirmed that adding this line as an override fixed their issues with this snap.

[d-loose]

I don't think we have an issue for this and I'm not aware of any icon related issues currently. Do you have more information about the problem this is solving?

According to the GNOME debugger App Center has its wmclass correctly set to snap-store

This is also in line with what we have for GNOME Software here.

[Nightmayr]

I see this no icon in the dock issue when using the snap on Fedora. Ubuntu works as expected. Although as seen in the screenshot below the wmclass looks to be set correctly so I'm guessing it's unrelated to the issue this PR aims to resolve.

[JGCarroll]

As far as I know the general concepts, StartupWMClass is to aid the D.E with assigning icons to apps in the dash, but I'll admit I don't understand it perfectly. Reading around, it's a bigger issue on Wayland than X11 (because I think Wayland doesn't have a "concept" of an application icon in the same ways as X11), and I'd particularly seen a lot of references to this (outside of snaps too) with the KDE 6 release, which defaults to Wayland.

@Nightmayr would you mind giving the following a go on your Fedora install? It effectively just copies what this one liner would do anyway.

cp /var/lib/snapd/desktop/applications/snap-store_snap-store.desktop ~/.local/share/applications
xdg-open ~/.local/share/applications/snap-store_snap-store.desktop

and manually adding the line somewhere StartupWMClass=Snap-store, then saving :)

The change should take effect within a few seconds and hopefully reloading the Snap Store then shows the icon right for you. If not, you can delete the newly created file and the system will just go back to using the system provided version straight away.

It is weird that on X11/Gnome with the Flutter app Store, there's actually a slightly different capitalization on my system, it is Snap-store with a capital S.

[Nightmayr]

@JGCarroll No problem, I gave that a go and it now shows the correct icon, although the correct change for me was StartupWMClass=snap-store on GNOME/Wayland

[Feichtmeier]

This should not add any harm to default Ubuntu and is free desktop specification and is need for some (I don't remember which) desktop environments, but I am almost certain for KDE
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
however I am also quite sure that it needs to map the exact letters of the binary name, while the "Name" value can be whatever you want
For example in musicpod
https://github.com/ubuntu-flutter-community/musicpod/blob/main/snap/gui/musicpod.desktop
so this PR would need to change it to "snap-store" instead of "Snap-store"

[JGCarroll]

Sorry there's been no updates here, I'd looked around the codebase trying to evaluate how the wmclass value is being set. From what I've gathered it's mostly a X11 concept that lingers in Wayland to some extent but doesn't work the same way.

From what I've seen, adding this value without having a consistent value for all users could cause regressions, potentially more than it fixes.

Really what's needed is to understand why there's two values being used but from what I've seen so far, I hadn't been able to find one.

Edit: If it is, in Wayland, based purely on the binary name. I'd imagine what's going on is X11 has an explicit call to change the wmclass but Wayland doesn't. If that was true, then the easiest solution would be to update the snap to change the executable to Snap-store, which would in theory make X11 and Wayland have the same values and therefore work identically for both?

Otherwise the the inverse, if there's an explicit X11 call, can we override that back to snap-store lowercase S? (But I couldn't find one).

[Feichtmeier]

Sorry there's been no updates here, I'd looked around the codebase trying to evaluate how the wmclass value is being set. From what I've gathered it's mostly a X11 concept that lingers in Wayland to some extent but doesn't work the same way.

From what I've seen, adding this value without having a consistent value for all users could cause regressions, potentially more than it fixes.

Really what's needed is to understand why there's two values being used but from what I've seen so far, I hadn't been able to find one.

Edit: If it is, in Wayland, based purely on the binary name. I'd imagine what's going on is X11 has an explicit call to change the wmclass but Wayland doesn't. If that was true, then the easiest solution would be to update the snap to change the executable to Snap-store, which would in theory make X11 and Wayland have the same values and therefore work identically for both?

Otherwise the the inverse, if there's an explicit X11 call, can we override that back to snap-store lowercase S? (But I couldn't find one).

No, once the snap binary name is set/registered, it can no longer be changed

[JGCarroll]

There's two binaries at play, /snap/bin/snap-store pointing to /snap/bin/snapd, and the actual $SNAP/bin/snap-store that gets used, I'd be hopeful it's the second that gets used for the wmclass out of the two, I'd have to check when I've some free time, likely in a Fedora VM.