Very ugly cursor for Spotify and KDE snaps

When I created this issue one year ago all KDE snaps,
now after checking back I think some have updated their gtk-common-themes. But I can give you a list later.

@Igor thank you for intiating/thinking about this, really great :slight_smile:
I think this could be really beneficial for the overall user experience since Spotify is so popular

As far as I know, I fixed the issue for the KDE extensions about a year ago, so any KDE snap using the extension should have this issue fixed. A list of snaps who still have this issue would be great. They probably need to be ported to the extension.

1 Like

I personally think the current setup of the theme content snaps is great. Snaps just need to be updated to use them, and we need the automatic theme installer in place.

The current solution is the Snapcraft extension system. That automatically adds a number of best-practice features to the developer’s snap, and often means that rebuilding the snap with a new version of Snapcraft will improve the snap’s experience. It is something that the developer needs to opt in to though.

It can lead to some changes in behaviour, so is something the developer would need to test. For similar reasons, injecting lots of new content into the sandbox of existing snaps is liable to break the compatibility guarantees that developers are relying on.

As Spotify was a fairly early adopter of the Snap ecosystem, most of these improvements post-date them. They are likely using a snapcraft.yaml file that works for them and haven’t really seen a need to change it. That’s why I said this might be better handled as an advocacy issue rather than a technical issue.

The current solution of extensions does not go far enough.

It does not cover all of the visual/desktop elements. But more importantly, it requires developers to make a change to their snap, which can be complicated or non-trivial in their setup.

Meanwhile, the end user launches a standard Linux app and then a snap counterpart, and they see a visual difference. They won’t necessarily care whose “fault” it is, or “blame” developers for not bundling the latest specification in the toolchain - they will simply assume that snaps do not work or integrate into the system as well as the traditionally packaged software.

We cannot expect 100s or even 1000s of developers to adopt extensions, because it entirely relies on the other party, and it is not a consistent process. Instead, if we provide a common framework that will apply to all snaps, we can ensure the end user gets a consistent experience.


Can you be more specific about what elements are missing?

And I’ll repeat: we decided against e.g. simply mounting the host system /usr/share/themes into the snap sandbox because it simply didn’t work. One big example was that GTK made massive changes to its CSS theming system in version 3.20. If you had a snap built against 16.04 libraries, it likely wouldn’t be able to use theme data from newer distros unless the theme included both 3.18 and 3.20+ versions. Similarly, snaps built using 18.04 or 20.04 libraries may not function correctly with the older versions of themes found in old distro releases. That’s one of the big reasons we opted to distribute theme data for snaps as snaps as well.

[this is also the approach Flatpak adopted, fwiw]

I will share something in the coming days. But in essence, I changed on the host color scheme, font size, scaling factor in the Plasma desktop, etc, and in most cases, there are differences between the traditional apps and the snaps.

I understand that there can be conflicts, but we can think of elegant ways of solving those that do not require user interaction. For that matter, we can “mount” themes from any gnome version - so the snap thinks it’s the real /usr/share/theme - we just provide all of the content to any snap with or without the explicit extensions declaration.

I’ll come back with more details, especially for HD displays, and a suggestion for implementation.


A lot of this sounds specific to KDE. I don’t mean to dismiss your experience, but rather to point out that a lot of these features do work on a GNOME based desktop. I’ve got fonts scaled to 150% on my laptop, and fonts in snapped GTK apps to match unsandboxed apps.

Note that GTK does not have the concept of colour schemes independent of the theme: themes like Yaru and Adwaita have the accent colour (and variations of that colour) baked into the CSS. Doing a quick search indicates that you can set the GTK theme in Plasma via System Settings -> Application Style -> Configure GNOME/GTK Application Style.

1 Like

It is not specific in any way to KDE.

BTW, I just shared a doc with you, and it shows results where even GNOME snaps (including stock Ubuntu stuff) fails these different tests on Ubuntu/Kubuntu. The things get worse for any Qt-based apps, which form a significant portion of Linux software.

We support snaps on 40+ distributions. We need to make sure the users of these distributions get a consistent experience with snaps.


FWIW, I would like to share my thoughts of what is missing in flatpak, snap & Qt to make them compatible and make Qt apps look like on the host

  1. The first thing that should be understand-ed is, unlike gtk (that has its own theming system built with CSS and its own configuration system built with dconf), Qt’s internals are made in a way so that it relies on system toolkit to provide correct look’n’feel.

  2. Since Linux ecosystem doesn’t have a ‘system toolkit’, Qt on Linux uses platformtheme plugins and style plugins. First ones should be provided by DEs to get their settings, last ones control how standard widgets would look like. Both of them are written in C++, so you can’t just pick up them from the host.

  3. A lot of time ago, in the time of gtk2, Qt had both a platformtheme plugin and a style plugin based on gtk2. That was a great time when Qt applications looked like gtk ones in gtk environemnts. Then gtk3 was released and now Qt has only gtk3 platformtheme plugin. I don’t know why there’s no gtk3 style plugin, I’ve heard that gtk removed APIs that are needed to implement something like that. Or maybe they just don’t have enough time & interest to rewrite it to new APIs (if there are any)…

  4. Since there’s no ‘system toolkit’ and no gtk style plugin anymore, people are doing hacking. Plasma has its own platformtheme plugin that can read settings via the org.freedesktop.portal.Settings interface, but if the user changes widget style in KDE settings, you kinda suck (since you can’t embed all the style plugins in the world). For GNOME, Fedora community made the QGnomePlatform platformtheme plugin and Adwaita-qt style plugin that just mimics the default GNOME theme and once the user changes theme, you kinda suck again. On other environments, it’s de-facto standard to use qt5ct configuration tool that provides a platformtheme plugin + Kvantum theme engine that provides a style plugin. What’s good in that case is that these themes are just ini + svg, so theoretically you can try to use them from the host. What’s bad is that they aren’t portal aware and get the configuration from ini configs. But I think once someone adds that support, this can be a great tooling that works really good in confined environments. The other, more ‘legacy’ standard is to use qt5ct + gtk2 style plugin on these environments. People really love that since they can make their look’n’feel unified without looking for a theme that has both gtk + kvantum variants, so a lot of people still use it.

  5. Qt has no way to get some settings on Wayland. E.g. on X11 they used libXCursor to get cursor theme and size (it gets these settings from Xrdb, X Resources Database), but on Wayland there’s no any standardized protocol to configure cursor theme & size, so they just reading environment variables. There’s a proposal for such a standard, but GNOME people sabotaged its accepting by saying ‘we don’t need that, use dbus for this’, so here’s no work on it.

  6. Here’s no way to get consistent decorations on Wayland. Not all toolkits want to draw decorations on their own, e.g. Qt has a dummy called bradient that looks really ugly:

    (taken from here)
    In order to avoid that, GNOME should support the xdg-decoration protocol, like both Plasma and Sway (the only mature Wayland compositors that I know) do.

Here’s the best way I see to solve all these issues:

  1. Let GNOME implement xdg-decoration
  2. Let xcursor-configuration to be standardized and be used by GNOME, Plasma and Sway.
  3. Standardize settings keys for org.freedesktop.Settings, make gtk use them and create a platformtheme plugin (hopefully in Qt tree) that will read them.
  4. Make some theme engine that will be used by both gtk & qt on Linux in all desktop environments and be sandbox-friendly.

Some tradeoff variants:

  1. Implement gtk3 style & decoration plugins for Qt, create appropriate gtk APIs for that if there’s none. Or you can go Fedora way and implement Yaru style & decoration plugins. You can also implement Yaru as a Kvantum theme and maybe extend Kvantum to let it handle decorations.

  2. Move cursor configuration to platformtheme abstraction, let Qt get cursor settings from gtk and from Plasma (and other DEs, like LXQt) settings.

  3. Create qt-common-themes, put the standard Qt’s gtk3 platformtheme plugin, Plasma’s platformtheme plugin, Plasma’s Breeze & Oxygen style plugins, LXQt’s platformtheme plugin, qt5ct’s platformtheme & style plugins, Kvantum’s style plugin, QGnomePlatform’s platformtheme & decoration plugins, adwaita-qt’s style plugin. Maybe some common Kvantum themes also if you consider that loading them from the host is too dangerous. Maybe add portal support to qt5ct & kvantum.


I’ve been going over some of the data that @igor put together, and it did present a few opportunities to improve the experience for various snaps.

GTK snaps do not support colour schemes on KDE desktops

GTK 3 does not natively support colour schemes, but the combination of the breeze-gtk theme and kde-gtk-config helper services manage to support the feature for KDE Plasma’s default theme.

The settings are not communicated in the same way other GTK theme information is: instead, there’s a daemon that will write CSS files to ~/.config/gtk-3.0/ to override symbolic colour names used by the Breeze theme’s CSS, and a GTK module to try and reload the CSS whenever it changes on disk.

Having apps load the colours in effect on app launch should not be too difficult:

  1. update snapd’s desktop interface to grant owner @{HOME}/.config/gtk-3.0/*.css r access in the connected plug AppArmor rules.
  2. update the desktop-launch script generated by Snapcraft’s various gnome-* extensions to symlink all CSS files from the user’s real home directory to $SNAP_USER_DATA/.config/gtk-3.0/.

Supporting runtime changes to the colour scheme may be a bit more tricky. At first I thought it might be enough to include the colorreload-gtk-module GTK module in the various GNOME platform snaps. But given that it works through an inotify watch, it would be unlikely to detect changes to the symlink targets.

Qt snaps don’t follow theme settings on older KDE desktops like Kubuntu 18.04

The KDEPlasmaPlatformTheme platformtheme plugin for Qt tries to use the org.freedesktop.portal.Settings portal interface to read various desktop configuration settings when it detects that it is running under either Flatpak or Snap confinement.

The support for this portal in the xdg-desktop-portal-kde backend began in November 2018, so the support services outside the sandbox don’t know how to provide the information the snap is asking for.

We can’t easily fix every distro, but we could help Kubuntu users by SRU’ing new versions of xdg-desktop-portal and xdg-desktop-portal-kde.

Qt snaps don’t follow style on GTK desktops

We’re probably never going to get this 100%, but we can do better. At a bare minimum, Qt’s gtk3 platformtheme plugin should mimic a number of GTK settings. Snapcraft’s kde-neon extension even tries to ensure the app uses it:

However, the gtk3 plugin is not provided by e.g. the kde-frameworks-5-qt-5-15-core20 platform snap (this is mentioned in snapcraft PR #3226 where the above script fragment was added).

If it would improve integration of these apps on more desktops, then perhaps it would be worth trying to persuade the maintainers of the kde-frameworks-* platform snaps to include the plugin. It looks like most of GTK’s dependencies (GLib, Cairo, Pango, gdk-pixbuf) ar already in the snap, so it may not add that much weight.

On the more general subject of Qt plugins, I’m not sure it really makes sense to try and separate them into separate snaps. In particular:

  1. Qt expects all plugins of a type to be present as shared libraries in a single directory, which doesn’t easily map to the way plugging the content interface to multiple slots operates. Also, the plugins are often not self-contained to a single shared object: they often pull in other libraries.
  2. Qt plugins generally end up linking to Qt private APIs (e.g. the gtk3 and xxx plugins require the Qt_5_PRIVATE_API symbol version from Mixing plugins built for one Qt version with libraries from a different Qt versions often refuses to function.

So if there are other Qt plugins that are needed by common desktops, it would be worth investigating if they can easily be included in the platform snaps.


Thank you James, for the very detailed analysis!

I will ping the KDE folks and point them to this thread. Hopefully, this will get the right momentum going!


This hack is not needed, Qt checks gtk based desktops on its own. Moreover, once gtk3 platformtheme plugin will be added, portal dialogs will be broken since this vairable has a priority over the special case

1 Like

Looking through some of the code, it looks like the xdgdesktopportal platform theme plugin tries to act as a filter for whatever plugin that themeNames function returns. If xdgdesktopportal and gtk3 are used together, we should get portal file dialogs together with the font returned from the GtkSettings object (so either XSETTINGS or the settings portal).

So we’re probably best off making sure the xdgdesktopportal, gtk3 and kde platform theme plugins are available with whatever Qt distro the snap uses, and either make sure QT_QPA_PLATFORMTHEME is unset or set to xdgdesktopportal.

1 Like

The issue has been fixed :slight_smile: :sun_with_face:

Thanks whoever worked on this :+1:


Its fixed for Spotify, but still broken on others snaps like KolourPaint from KDE or VLC player.

1 Like

It’s because Qt uses Xcursor via dlopen, so apparently KDE maintainers forgot to add it to their runtime. Someone who have the contact with them should suggest to add the library to their runtime and that should be fixed.