Added StartupWMClass=snap-store to the .desktop file.#2009
Added StartupWMClass=snap-store to the .desktop file.#2009Kyuyrii wants to merge 1 commit intoubuntu:mainfrom
Conversation
|
I noticed that I didn't communicate very well; the problem isn't just when the Snap Store is pinned to the panel. In the video below, I demonstrate the situation and then use the modified .desktop file to resolve it. 2026-01-18.14-35-14.mp4 |
aleasto
left a comment
There was a problem hiding this comment.
LGTM. As for why this is necessary:
The traditional logic for matching a window with an application is for the client to identify itself with an app-id that must match either the .desktop filename (here mangled by snapd into snap-store_snap-store) or the StartupWMClass entry of the desktop file. Unless instructed otherwise, a GTK3 window will identify itself using the filename of the binary executable (here snap-store).
On top of that some desktops like GNOME Shell can recognize that the application is sandboxed, and will ignore the application-provided identifier (could be maliciously impersonating a different app) and always match it against its sandboxed identifier (always trusted, provided by the system): this is why GNOME can show an icon even without this change.
Currently, when pinning the Snap Store to the KDE panel and opening it, it is not considered the same app that is pinned and uses the yellow icon that symbolizes Wayland.

By modifying the .desktop file to add StartupWMClass=snap-store, the problem was resolved:
