Gnome-3-28 extension: add gsettings to plugs

snapcraft
1

I created a PR to add gsettings to the plugs in the gnome-3-28 extension. The contributing guidelines said to discuss the PR here?

https://github.com/snapcore/snapcraft/pull/2735

The gsettings plug is needed for GTK applications to use the correct theme under Wayland. As a result, every GTK application should add this plug, so it seems better to just do it in the extension itself.

2

For reference: I omitted gsettings when writing the extension because not all apps store their data within it and it can be used to leak configuration from other installed apps. I wasn’t aware that Wayland would require the use of gsettings.

3

@jamesh and I discussed the gsettings interface in Paris and relatively recent and upstream changes. IIRC, there was something specific wrt themes, but I don’t have the details. Keep in mind, the gsettings interface today gives quite a bit of access that is not snap-specific and it would be best to not rely on it long term. That said, I don’t think that we necessarily have a choice at this point. @jamesh, can you comment?

4

Not sure if it’s related but @jamesh explained some of the issues on the Ubuntu community hub.

Under Wayland, GTK selects its theme based on a configuration value stored in gsettings/dconf. If you haven’t ever changed a configuration value, then it won’t be present in your user dconf database and the default value will be taken from the gsettings schema. The problem occurs because snap confined apps see a different set of gsettings schemas, so some configuration values may look different.

So while on Cosmic the default value for gtk-theme might be Yaru, a confined application using libraries/data from Xenial might instead see Ambiance.

When you used the tweak tool to switch back and forward between themes, you’d likely no longer be relying on the schema default value for your theme. In turn you’d now see Yaru for those confined applications.

None of this applies if you are using the default X11 session though (or have X11 apps running throught Xwayland on the Wayland session). In that case, the theme name is communicated via the XSETTINGS protocol and should be consistent for confined and unconfined applications.

We don’t yet have a good solution for the bug I referenced. As a workaround, it might make sense to update the gnome-platform snap to set Yaru as the default theme in its schemas: this would make no difference to X11 sessions, and people using Wayland are more likely to be on the latest release rather than aiming for LTS stability.

This is now fixed in upstream by using the settings portal: https://gitlab.gnome.org/GNOME/gtk/issues/1343

From what I gather, the settings portal should also fix the issue of apps trampling over each other’s configuration. Does snapd support the settings portal? (or any portal; I’m not able to find any documentation or snaps actually using portals)

5

As things stand at the moment, an app should be able to select the correct theme provided the following holds:

  1. a sufficiently new version of xdg-desktop-portal is available on the host (>= 1.1.0).
  2. a sufficiently new version of GTK is available within the sandbox (>= 3.24.2)
  3. GTK believes it should use the portals API (at present, setting GTK_USE_PORTAL=1 in the environment).

If all that lines up, then the app should be able to select the correct theme with just the desktop interface.

Unfortunately we’re not yet at a point where we can depend on (1) and (2). Both Xenial and Bionic ship older versions of xdg-desktop-portal (something we’ll want to fix at some point), and the gnome-3-28-1804 snap ships a too old version of GTK.

So as things stand, snaps built using the gnome-3-28 extension will need the gsettings plug to correctly pick up the system theme when running on a Wayland system. Hopefully that will change for the next version of the extension.

1 Like