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:
- update snapdās
desktop
interface to grant owner @{HOME}/.config/gtk-3.0/*.css r
access in the connected plug AppArmor rules.
- 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:
- 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.
- 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.