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.
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:
@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:
@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/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
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
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:
- add new CSS rules to the theme that aren’t matched by the old GTK release.
- split the theme into a new and old version. For instance, Ubuntu’s Ambiance theme provides
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
Based on @jamesh explanation, +1 to auto-connect.
@niemeyer - can you also weigh in/vote?
Note enough votes to tally.
@reviewers (in particular @niemeyer) - can one/some/all of you vote on this?
Based on the explanation above:
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.
@kenvandine - can you comment on @niemeyer’s response?