Very ugly cursor for Spotify and KDE snaps

snap
31

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 libQt5Gui.so.5). 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.

8 Likes