Very ugly cursor for Spotify and KDE snaps

Hello there,

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.

Best regards,
Frederik

What’s wrong?

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:

content[icon-themes]      snap-name:icon-themes       gtk-common-themes:icon-themes`

How to solve this

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.
1 Like

I’m experiencing a similar issue. I’m new as far as snaps go, although I feel like this is a symptom of sandboxing.

EDIT: A key note is that I’m running on X11 - Could this be the case where the XSETTINGS isn’t set up properly to get the default cursor?

I’m running chromium version 81.0.4044.138 on xubuntu 20.04, the snap version I’m using described here:

λ snap info chromium
name:      chromium
summary:   Chromium web browser, open-source version of Chrome
publisher: Canonical✓
store-url: https://snapcraft.io/chromium
contact:   https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bugs?field.tag=snap
license:   unset
description: |
  An open-source browser project that aims to build a safer, faster, and more stable way for all
  Internet users to experience the web.
commands:
  - chromium.chromedriver
  - chromium
snap-id:      XKEcBqPM06H1Z7zGOdG5fbICuf8NWK5R
tracking:     latest/stable
refresh-date: 2 days ago, at 17:20 EDT
channels:
  latest/stable:    81.0.4044.138 2020-05-06 (1143) 161MB -
  latest/candidate: 81.0.4044.138 2020-05-06 (1143) 161MB -
  latest/beta:      83.0.4103.44  2020-05-08 (1144) 163MB -
  latest/edge:      84.0.4128.3   2020-04-29 (1136) 164MB -
installed:          81.0.4044.138            (1143) 161MB -

The connections listed includes the gtk-common-themes slot:

λ snap connections chromium 
Interface                 Plug                               Slot                            Notes
...
content[gtk-3-themes]     chromium:gtk-3-themes              gtk-common-themes:gtk-3-themes  -
content[icon-themes]      chromium:icon-themes               gtk-common-themes:icon-themes   -
content[sound-themes]     chromium:sound-themes              gtk-common-themes:sound-themes  -
...

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?

1 Like

Well, then, do you know of any effective way of “bugging” Spotify (without installing hidden mics :slight_smile: )? 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 :smile:

This gtk-common-themes merge request should improve the situation for the fallback cursor theme.

1 Like