I’ve been thinking about this a bit. I think we’ve categorically ruled out exposing the system themes directly, since that poses both a backward and forward compatibility problem. So we want some way for a snapped application to access a theme provided by a second snap.
We probably don’t want to model this relationship on the existing interface connection semantics because on multi-user systems different users could potentially have different themes. Rather, we probably want the app to say “I’m interested in
gtk-3.20 themes”, and then be given access to all installed
gtk-3.20 theme snaps. It’s also worth noting that an app will probably be interested in multiple types of theme resources. A typical GNOME app will want:
- the GTK theme
- a matching icon theme
- a matching mouse cursor theme
So I think we probably want something similar to Flatpak’s extension point idea, which is kind of like our content interface, but in reverse. Something like the following:
application snap A says it is interested in the
theme.gtk-3.20 extension point, and wants it exposed at
theme snaps B and C say they provide the
theme.gtk-3.20 extension point at
snap-confine configures A’s mount namespace by doing the equivalent of:
mount -t tmpfs none /snap/A/current/themes
mount --bind /snap/B/current/gtktheme /snap/A/current/themes/B
mount --bind /snap/C/current/gtktheme /snap/A/current/themes/C
Whenever new snaps providing the extension point are installed, A’s mount namespace is updated.
We could then rely on something like the
desktop-launch script to update
$XDG_DATA_DIRS to make themes under these extension point directories discoverable.
In the above example, I’m using the snap package names under the extension point. This would make it difficult to show up with a name like
Ambiance, since we don’t allow upper case in package names. It would also be a problem if we wanted separate snaps providing the
theme.gtk-3.20 extension points for that theme name.
Flatpak’s solution to this is to make the names of extension points the prefix of the names of the packages that provide that extension, and then use the suffix as the file system path. That guarantees that there isn’t any conflicts by passing the job on to the person managing the repo/store. It’s not clear that is the right option for us with our flat package naming scheme though.
Icon themes will probably add some more complication, since they have the concept of inheritance. For example, the default
ubuntu-mono-dark theme says it inherits from
hicolor. Would we expect the snapped version of the theme to be flattened to get rid of the dependencies, or do we need to expose that dependency metadata so that whatever component installs the theme snaps can follow them?
I’m sure there is some more to consider, but hopefully this is enough to start with.