When working on the
gtk-common-themes snap, we focused on GTK 3 themes because they represented what most new apps were using, and had the benefit of being safe declarative CSS.
However, there are still a fair number of apps relying on GTK 2 theming:
- Electron 1.x apps.
- Qt 4 apps
- GTK 2 apps
So I’ve started looking at coming up with a solution for these apps too. This is taking the form of a new
gtk2-common-themes snap, which is being maintained here:
I’ve chosen not to integrate this into
gtk-common-themes mainly because the native code theme engines mean it can’t be part of an architecture independent snap. As we’re not including icon themes in this snap, the snap is fairly slim, currently coming in at 280K on amd64.
We haven’t published the snap to the store yet but it should build fine with
Using the snap
gtk-common-themes, an application snap needs some modifications. I realise the boilerplate is undesirable, and we plan to get rid of it when migrating snapcraft-desktop-helpers over to the new Snapcraft templates feature.
First up is the plug definitions:
There are two plugs for GTK 2: one for the theme engines, and the other for the theme definitions. And lastly we’re plugging icon themes from the main
gtk-common-themes snap: this is needed to provide both icons and cursors.
The snap will also need to be modified to create the mount point directories:
And in order to let GTK find the theme data, we need to set some environment variables:
XDG_DATA_DIRS variable allows the app to find icons/cursors. The
GTK_DATA_PREFIX variable makes the theme definitions available (unfortunately GTK 2 doesn’t respect
XDG_DATA_DIRS for this). The
GTK_PATH variable is needed to find the engines.
GTK_PATH to work correctly depends on a pending change to snapcraft-desktop-helpers:
Third party themes
I’ve configured the
gtk-2-themes slot so that it will be possible for third party theme snaps to be plugged simultaneously with
gtk2-common-themes. This is still mostly experimental though, since we still don’t have a facility to locate, install, and plug extra themes.
Unfortunately the layout of the GTK modules directory isn’t amenable to this, so only one provider will be able to be plugged at once. Given that theme engines are shared libraries that get dynamically linked into the application, I’m not sure it is a bad thing if we restrict engines to those provided by
At present, I’ve included just the engines needed by the common default themes:
I’d be open to adding more on request.
What about base snaps?
As GTK 2 engines are native code, an open question is how compatible they are over different base snaps. GTK 2 itself is pretty much static these days, with the occasional 2.24.x point release for bug fixes but no new forward/backward incompatible changes.
The engines are C and only link to GTK libraries plus libc/libpthread, so I think there is a good chance that the libraries will work on
core18, or anything else with a glibc at least as new as xenial. But perhaps it would be worth playing it safe, and have different
-engines content slots for each base. I’m not sure what the best option is at present.