The Ubuntu Desktop team has created the gtk-common-themes snap which provides common gtk3, icon and sound themes. These themes are exposed via the gtk3-themes, icon-themes and sound-themes interfaces. We would like a snap declaration to auto-connect these interfaces.
default-provider: gtk-common-themes
For more details see Supporting desktop themes via the content interface
Thanks for your consideration
Today we have a process for content snap auto-connections, but this snap (perhaps understandably) doesnāt follow this convention.
Here are the relevant parts of the snap.yaml:
name: gtk-common-themes
...
slots:
gtk3-themes:
interface: content
source:
read:
- $SNAP/share/themes/Adwaita
- $SNAP/share/themes/Adwaita-dark
- $SNAP/share/themes/HighContrast
- $SNAP/share/themes/Ambiance
- $SNAP/share/themes/Radiance
- $SNAP/share/themes/EvoPop
- $SNAP/share/themes/EvoPop-Azure
- $SNAP/share/themes/Arc
- $SNAP/share/themes/Arc-Dark
- $SNAP/share/themes/Arc-Darker
- $SNAP/share/themes/Communitheme
icon-themes:
interface: content
source:
read:
- $SNAP/share/icons/Adwaita
- $SNAP/share/icons/hicolor
- $SNAP/share/icons/HighContrast
- $SNAP/share/icons/Humanity
- $SNAP/share/icons/Humanity-Dark
- $SNAP/share/icons/ubuntu-mono-dark
- $SNAP/share/icons/ubuntu-mono-light
- $SNAP/share/icons/DMZ-Black
- $SNAP/share/icons/DMZ-White
- $SNAP/share/icons/Solus
- $SNAP/share/icons/communitheme
- $SNAP/share/icons/Suru
sound-themes:
interface: content
source:
read:
- $SNAP/share/sounds/communitheme
@kenvandine - I think you have a bug in that all these things are in $SNAP/usr/share/ā¦ (you omit āusrā).
AFAICT, the exported files for themes, icons and sounds are all data files. There are css and xml files for the themes though. @kenvandine-- are these expected to work everywhere or do they require use of a particular core, base or other content (eg, gnome-3-28) snap?
@niemeyer - please weigh in on what you think this should look like.
This was based on the outcome of those theming sessions we had in Budapest.
Iām not sure omitting āusrā is a bug, the important thing is the target in the snap using this has to include āusrā.
For example, this is from gnome-calculator:
gtk3-themes:
interface: content
target: $SNAP/usr/share/themes
default-provider: gtk-common-themes
icon-themes:
interface: content
target: $SNAP/usr/share/icons
default-provider: gtk-common-themes
sound-themes:
interface: content
target: $SNAP/usr/share/sounds
default-provider: gtk-common-themes
@jamesh do you have any thoughts on those paths?
When I unpacked the snap, squashfs-root/share/icons/Adwaita (et al) did not exist, but squashfs-root/usr/share/icons/Adwaita did. I thought since $SNAP/share/icons/Adwaita is used as the āreadā and that wonāt exist when the snap is installed, this was a problemā¦
@niemeyer - can you confirm that the snap.yaml is how you envisioned this to work wrt auto-connection?
Looking at the installed snap I see /snap/gtk-common-themes/current/share/themes/Adwaita
Perhaps I pulled an old revisionā¦ /me shrugs
Hi, I installed the snap, in linuxmint 18.3, but I do not know how it works. I have an application with a transparent border and I do not know how to do it to give it a theme from the gtk common theme snap. Some help?
@Lvaskz The gtk-common-themes snap provides themes for other snaps to use, however for the snaps to use it the developer needs to update their snap to use the content interface to access themes. This is a new feature, itāll take time for snaps to add support for this.
Ok, I will wait. Thanks for answer. 
On the subject of /usr/ in the paths, there is no reason why it has to be the same between the plug and slot snaps.
The gtk-common-themes snap places its theme data in $SNAP/share/themes, $SNAP/share/icons, etc, but an application snap could have the content bind mounted under $SNAP/usr/share/themes with no ill effects. On the plug side, all thatās important is that the theme data can be found in $XDG_DATA_DIRS.
When we eventually get third party themes on the store managed by their upstreams, they could internally store their theme data under $SNAP/usr/share if they want: all that is important is that they export the expected content in the expected format.
Is there any blocker for the auto-connection? As I understand it is needed for the theming of built-in snaps when using communitheme. As it is, the experience is a bit broken, which is a shame as communitheme is shaping really nice otherwize.
I havenāt seen a proper response above to the point raised by @jdstrand about the content names. We discussed this at length in the linked topics. Why was that style not followed here?
More specifically, what is exposed by these interfaces, and what are the compatibility concerns that we need to keep in mind as the shape of that content changes? Were the interfaces designed accounting for that? How so?
The content interface IDs were chosen based on an assessment of the compatibility issues you bring up. I donāt think it is appropriate to tag any of them with a reference to a particular base snap: Iād expect that apps built using core, core18, or a future Fedora base snap would all use the same theme data.
Icon themes consist of a set of image files, an index.theme file holding metadata described here, and optionally an icon-theme.cache file described here. These formats have remained stable for longer than Ubuntu has existed, and there are multiple independent code bases relying on the layout and file formats. I donāt expect it to change any time soon.
Sound themes are a more recent development, but again rely on a specification similar to icon themes and not linked to a particular toolkit or even a particular build of a particular toolkit.
GTK themes underwent a dramatic change with the release of GTK 3.0, switching from a combination of binary ātheme enginesā and custom configuration files, to using CSS. So gtk3-themes seemed to be the right amount of versioning for the interface ID. We donāt know what changes will be required with GTK 4. If we ever try to address GTK 2 themes, it will have to deal with all the problems inherent with native code plugins.
Now it is true that themes do get updated with new GTK minor releases. These are usually handled by theme authors in one of two ways:
gtk-3.0/gtk.css and gtk-3.20/gtk.css in itās theme folder: the first used by GTK < 3.20, and the second used by everything newer.While (2) might sound like a reason to have more strongly versioned interface IDs, not every theme does this and not every theme that offers version specific CSS splits on the same releases.
Also, when a theme decides to try and offer different behaviour based on GTK version, the different versions are rarely independent. They might reference the same image resources, or even import common CSS files. So I think we are best served to just have a single gtk3-themes slot.
Note enough votes to tally.
@reviewers (in particular @niemeyer) - can one/some/all of you vote on this?
Based on the explanation above:
+1
A worried +1ā¦ specification is relatively recent, and unclear if itāll survive as-is and across systems
-1 but only due to name style, and +1 if itās changed to gtk-3-themes, as we have precedence of gnome-3-24-1604, and also because we may need foobar-3-1-themes in the future, which looks awkward as foobar3-1-themes and unlike what we have.