-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add StartupWMClass to .Desktop file #1706
base: main
Are you sure you want to change the base?
Conversation
Fixes instances where the application does not have an icon in the dock and appears with a generic window icon.
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 This is also in line with what we have for GNOME Software here. |
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.
and manually adding the line somewhere 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 |
@JGCarroll No problem, I gave that a go and it now shows the correct icon, although the correct change for me was |
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 |
Sorry there's been no updates here, I'd looked around the codebase trying to evaluate how the 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 Otherwise the the inverse, if there's an explicit X11 call, can we override that back to |
No, once the snap binary name is set/registered, it can no longer be changed |
There's two binaries at play, |
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.