I've discovered something about snap themings

snapd
1

Is there a topic on here for this already? :slight_smile: I think I remember reading on here about snap theming issues on Ubuntu 18.10…

2

The team is on it already. @willcooke and @kenvandine will have more details.

2 Likes
3

For those not following on the Ubuntu Community site, the root cause is confined applications seeing different gsettings configuration defaults to unconfined applications. This is due to the confined app seeing a different set of gsettings schemas to the rest of the desktop.

For instance:

$ gsettings get org.gnome.desktop.interface gtk-theme
'Yaru'
$ snap run --shell gnome-calculator
...
$ $SNAP/bin/desktop-launch gsettings get org.gnome.desktop.interface gtk-theme
'Ambiance'

This isn’t a snap specific problem, also affecting other confinement systems like Flatpak. We can probably work something out that will mostly do the right thing on most Ubuntu releases, but there is no general solution without e.g. enabling a different gsettings backend that does the settings lookup outside of the sandbox.

2 Likes
4

I’m not familiar with the way the isolation works. Can someone describe in more detail the setup which takes place and ends up with different settings inside and outside? I see how we want some isolation, but it’s also clear we want some flow between these two worlds, so I’d be interested in hearing more about the exact setup we have so that we can brainstorm some way for that flow to take place.

5

With the example given above, the lookup is something like this:

  1. if a value for the setting is available in ~/.config/dconf/user, return that value
  2. otherwise, return the default value based on data in /usr/share/glib-2.0/schemas (a combination of XML .gschema.xml files and ini-style .gschema.override files).

On Cosmic, we have /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override that contains:

[org.gnome.desktop.interface:ubuntu]
gtk-theme = "Yaru"
icon-theme = "Yaru"
cursor-theme = "Yaru"

In /snap/gnome-3-26-1604/current/usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override (based on Xenial’s packages), we have:

[org.gnome.desktop.interface:ubuntu]
gtk-theme = "Ambiance"
icon-theme = "ubuntu-mono-dark"
cursor-theme = "DMZ-White"

So while the gnome-calculator snap can access ~/.config/dconf/user, I haven’t changed the theme from the default leading to two different results.

1 Like
6

Thanks for the details. We need a way to export specific schemas, probably with filtering of keys, into the snap itself. Looking at the list of keys of org.gnome.desktop.interface, almost all of it would make sense to have respected inside the snap.

The desktop interface can whitelist a specific location for that, but we’ll also need to generate the file in the first place. The userd might be a good place for that?

There’s also the concern of compatibility, of course. Exporting content into the snap like that is always risky in terms of future changes.

1 Like
7

I agree that exporting all of /usr/share/glib-2.0/schemas to the snap is a bad idea: that would effectively be an oracle into what software is installed on the computer (event more so than access to the dconf database).

So one option would indeed be to copy a known set of schemas plus all the override files from ${XDG_DATA_DIRS}/glib-2.0/schemas to a private directory and run glib-compile-schemas on it.

One other idea that has been floated is to write a new gsettings backend for glib that would proxy calls for at least some configuration values to a daemon living outside of confinement (quite possibly part of xdg-desktop-portal), so it can get see the unconfined defaults. One benefit of this is that it might make it easier to run without access to the user’s full dconf database too: rely on the sandbox’s schemas for other keys, and store settings in a private database.

1 Like
8

That sounds good. We can even filter specific keys of the schema if necessary, to make sure that the snap environment has the ability to respect the settings.

Even if we do something else inside glib proper later, we should probably start with this proposal now as it will offer greater compatibility with existing systems.

9

One other data point: the reason we haven’t moved faster to address this problem is that the specific case of theming is a Wayland only issue.

Under X11, GTK determines what theme to use by communicating with gnome-settings-daemon over the X socket (using the XSETTINGS protocol). As GSD is unconfined, it returns the correct value for the theme name.

It’s only Wayland apps where gsettings is used to determine the theme. That is issue GNOME/gtk#1343 that I mentioned in the Ubuntu Community thread.