Similar to the request to autoconnect GTK 3 themes content interfaces, I’d like to request the same for a set of content interfaces intended to provide GTK 2 theme data.
GTK 2 themes are comprised of two parts:
theme data files found in the same $datadir/themes hierarchy as other theme data. This is in a custom “gtkrc” format that sets various properties on widgets and applies “theme engines” to control how they are painted.
theme engines, which are native code shared libraries.
I’ve mirrored this division by providing the two components as separate content interfaces:
gtk-2-themes, provided by gtk-common-themes: the architecture independent declarative theme data.
gtk-2-engines, provided by gtk2-common-themes: native code theme engines required by the provided themes.
The gtk-2-themes slot is modelled after gtk-3-themes, in that it would allow multiple providers to plug into applications in future. I couldn’t work out a way to do the same for gtk-2-engines, but that isn’t necessarily a bad thing. There are relatively few theme engines, and I think they warrant tighter control since they are shared libraries that could potentially introduce arbitrary code into applications.
A description of how to write a snap that plugs into these interfaces can be found here:
One area that might warrant some debate is the naming of the gtk-2-engines interface (and perhaps the snap providing it). As the engines are native code, the obvious question is how they relate to applications using different base snaps. While there is a potential for incompatibilities, I think they are fairly low:
all the theme engines are comprised of C code without any dependencies outside of GTK’s dependencies, so e.g. 16.04 binaries are likely to work unchanged on an 18.04 base, and anything else with a glibc at least as recent.
GTK 2 itself is in maintenance mode, with the current 2.24.x series starting in January 2011. Furthermore, GTK’s module ABI has not changed since 2.10.0 (released in 2006).
With all that said, I’d be happy to include something in the interface name to signify the base if that is requested.
While they are low now I suspect that over time this will become an issue. Could we at least discuss how we’d like to resolve that down the line. Will there be ABI tags of some sort and the precise content connection will encode that (e.g. gtk-2-engines-glibc-123)? Do we want to involve the store in this?
I think we should not block on the implementation but we should not ship something that we need to design ourselves out of in 20.04
I’ve got no specific plans, but one option would simply be to introduce some versioning once we identify an incompatible base. For reference, here are the libraries the engines have DT_NEEDED tags for:
libgtk-x11-2.0.so.0
libgdk-x11-2.0.so.0
libpangocairo-1.0.so.0
libcairo.so.2
libpixman-1.so.0
libgdk_pixbuf-2.0.so.0
libgobject-2.0.so.0
libglib-2.0.so.0
libpthread.so.0
libm.so.6 (referencing version GLIBC_2.2.5)
libc.so.6 (referencing versions GLIBC_2.2.5, GLIBC_2.4, and GLIBC_2.14)
So we’re basically just looking at glibc plus the cairo and GTK 2 library stacks. The 2.14 release of glibc is dated June 2011, so you’d have to look back pretty far before these builds stop working.
Looking forward, I don’t expect glibc or GTK 2 to break compatibility. I’d also hope that we’d get to a point where no one needs GTK 2 any more.
It hurts a bit reading people dismissing snaps because of problems like theming, and seeing the general lack of answers even when a solution is provided like in this case. IMHO, this should be more of a priority to the snap team which seem rather unresponsive as of lately…
IIRC, since the request of this auto-connection, we’ve discovered that while gtk_3_ themes are architecture dependent, they haven’t been particularly release independent (please correct me). Before casting my vote, I’d like confirmation that this request for gtk_2_ themes remains unchanged.
There has been one significant theme breakage in the GTK 3.x series, when they made some changes to the elements the CSS was applied to for many widgets in GTK 3.20. This generally means that you need two versions of a theme: one for GTK 3.0-3.18, and one for GTK 3.20+.
Those can be provided simultaneously, which you can see with Ubuntu’s old Ambiance theme as an example:
$ ls -l /snap/gtk-common-themes/current/share/themes/Ambiance/
total 0
drwxr-xr-x 4 root root 217 Oct 25 21:13 gtk-3.0
drwxr-xr-x 3 root root 205 Oct 25 21:13 gtk-3.20
GTK 3 will read its theme from the gtk-3.x directory that is as close to the GTK version as possible (but not newer). So in this case, the gtk-3-themes slot is usable for both new and old GTK.
This of course relies on the theme to provide multiple versions. At present, Ubuntu’s new Yaru theme is GTK 3.20+ only, which leads to some ugliness. I’ve been working on a back port of the theme though, so that should be resolved next week:
Adwaita is fine too, since it is compiled into GTK.
Now back to the topic of GTK 2 themes…
As mentioned in the original post, handling multiple releases of GTK 2 is not much of a concern because it is effectively a dead branch of the library. Ubuntu has been shipping GTK 2.24.x releases since 11.04, and themes have remained compatible for a lot longer than that.
+1 for auto-connection with the requested names (gtk-2-themes and gtk-2-engines) for the gtk-common-themes snap. IMO, the name is fine since the gtk2 has been stable for many years.
That’s gtk-2-engines on the gtk2-common-themes snap, right? The slots are provided by two separate snaps due to their different nature (architecture dependence, different security concerns, etc).
@jdstrand: I just checked, and it looks like this has been set up incorrectly:
