Since the very release of the Spotify snap it always uses a wrong (in terms of not the cursor theme selected in the system or not the default cursor) and very ugly, fuzzy, tiny and awkward cursor.
I always thought it would only happen for Spotify but since I’ve started to install several KDE snaps I know this also happens for those.
What could be done to change that? I know there were apps like some electron apps that had this issue too and suddenly it was fixed for them.
Is this fixable by the app maintainers or is this related to snapcraft?
If it would be just a wrong colour okay, but it looks completely broken and fuzzy.
The issue is that these snaps do not use the icon themes from gtk-common-themes. That snap contains the cursor themes. Application snaps like spotify should connect to gtk-common-themes so they have access to all the common cursor themes. Without those cursor themes, the cursor will fallback to the ugly pixelated X11 one. Depending on what kind of snap it is, this is easier or harder to do. You can see whether a snap uses gtk-common-themes by running snap connections snap-name after it is installed. For cursors specifically, it should include the following line:
The easiest method is to use the gnome-3-28 extension. GTK apps and all other apps (except 32-bit apps, GTK+ 2 apps and Qt apps) should use the gnome-3-28 extension. However, many apps still use the older desktop helpers, which require you to manually add support for gtk-common-themes.
Spotify should probably upgrade to the gnome-3-28 extension. However, they might be more comfortable with only adding the gtk-common-themes snap. Since this snap is closed-source, there is not much more we can do except bugging them and providing good documentation.
The KDE snaps should, in my opinion, use the kde-neon extension. That extension adds support for the icon themes (I added this myself). The KDE Neon team, however, mostly still uses custom tooling which doesn’t automatically add the gtk-common-themes snap. The short-term solution is for somebody to take a look at the custom neon tooling and docs, and fix it so they also use the icon themes snap. All the KDE snaps are open source, so a community member should be able to go through all the snaps and add gtk-common-themes support. The long-term solution is for someone to reach out to the KDE Neon team and see what needs to be done for them to go all-in on the kde-neon extension.
Although I get the default X11 cursor when hovering over the instance.
This may be the wrong spot to poke to get the right answer. Is the case that the latest/stable branch doesn’t implement the gtk-3-themes extension yet, even though the proper connections are listed? Is there a case where the snap makes a connection to the gtk-common-themes extension but does not make use of it?
Well, then, do you know of any effective way of “bugging” Spotify (without installing hidden mics )? I’ve posted about this issue a long time ago in https://community.spotify.com/ and even linked to this thread, but they seem to mostly ignore anything Linux related. I remember Joy Sneddon lobbying them from OMG! Ubuntu some time ago (but maybe it wasn’t Spotify (?)). I think the fact that they have chosen Snap is great signalling, but then when you see the rough edges you put the blame on “Snap not being ready” while indeed it’s the packager’s fault in this case.
I think spotify is not connected to gtk-common-themes
and the fallback cursor in snap is this ugly, fuzzy, retro cursor.
I think at least @popey said something similar in the past
Sadly, after a long time of existence of the spotify snap it still does not use the yaru cursors, but this fuzzy, tiny, very broken looking “fallback” x cursor.
Could there please be anything done about it?
It feels like a real bummer when all the work does not show up in such a major application.
Best regards
In the case of Spotify, it doesn’t have any content interface plugs to pull in theme data of any kind. So there is very little that can be done from our side. It would require Spotify to update their packaging.
it surely can, but in snaps that do not use a theme snap via content interface as james described it can just be done by the snap author by including the right bits and setting the correct launcher variables … so only spotify themselves can fix it.
Okay, can’t this be somehow “lifted” up by Canonical? I know this is nothing “of my concern” but this is really much more of a visual issue that it might look for someone who does not care that much about visuals. I think this is really a big issue and looking at this spotify board, I don’t think raising an issue there with a “user voice” will get this fixed any time soon.
I’m not sure who would have contacts with Spotify. Maybe @Igor or someone on his team would know?
As far as helping snap authors add standard features like theme support, up to date GNOME stack, etc, we currently recommend using Snapcraft’s extension system. This preprocesses the snapcraft.yaml file to add features like content interface plugs to pull in theme data, and creating a command-chain script to make sure the app can see that theme data.
From the look of it, the Spotify snap is using none of that, so there is a limit to what we can do.
I’ll see if we can ping Spotify to make the right change. That said, I think relying on the publishers to adjust for every visual element - theme, icon, cursor, etc - on their own is not scalable, especially since they don’t face this problem with conventional packaging.
A solution could be to important user desktop settings into a common snap space that would be accessible to all of the snaps. Now, there can be problems, like incompatible themes, incompatible color schemes, etc, but this would remedy a lot of default issues.
Snapd creates a per-user directory (let’s call it $SNAPDUSER).
Snapd scans and takes desktop-specific content, like say /usr/share/themes and copies them into $SNAPDUSER.
Snapd exposes - automatically and transparently - contents under $SNAPDUSER - to every snap at runtime. With layouts, these can be made to match what apps normally expect on the Linux host, e.g.: ~/.gtkrc-2.0, ~/.kde4, ~/.config, ~/.icons, and so forth.
Optionally, Snapd can also filter out binary-incompatible components that do not match the snap-contained environment (e.g.: themes compiled for a newer version compared to the core).
This is just a broad outline.
But this could be done without user interaction, and without rebuilding of snaps. Content snaps definitely do their job, but since they rely rebuilding/refactoring, we end up with significant divergence - fonts, dpi, scaling, theming, color scheme, etc - as a result of the snapd confinement. To that end, the broadest, most comprehensive solution would be to transparently match outside-of-snap visual elements to those inside the snap.
With regards to Spotify itself, this was launched way back in 2017 at the Seattle Snapcraft Summit. Being that the packaging is that old, and likely hasn’t had much in the way of updating in the interim, it’s understandable that it’s not using extensions or content snaps of any kind (they didn’t exist back then)
I’m not sure what more we can do for Spotify since that’s an issue of the snap; not of the tooling, and the snap is maintained upstream. Afaik, Spotify was notified of this issue a long time ago.
)? I’ve posted about this issue a long time ago in 
I know this is nothing “of my concern” but this is really much more of a visual issue that it might look for someone who does not care that much about visuals. I think this is really a big issue and looking at this spotify board, I don’t think raising an issue there with a “user voice” will get this fixed any time soon.