Theme snaps for the flavors could be interesting. The flavors could seed the content snap for their theme. The tricky bit would be getting them auto connecting.
That is the eventual goal. IIRC we need some snapd changes to actually realize this though: namely having snapd auto-connect all available connectable slots to a plug, and connect new slots to existing plugs as they become available.
Let’s say I create a snap for my theme foo that provides the slots foo:gtk-3-themes and foo:icon-themes in the same fashion as gtk-common-themes does. Rather than connecting foo in place of gtk-common-themes, we’d want both slots to be connected to each snap plugging the interfaces. The reasons for this are:
on a multi-user system, users might have different themes selected. So there is no single slot that is correct to connect to the exclusion of others.
icon and sound themes include the concept of inheritance. For example, Ubuntu’s Yaru icon theme inherits from Humanity, Adwaita, and hicolor. If icons aren’t found in Yaru, the parent themes are then searched in turn for a match. A third party theme is likely to inherit from themes provided by gtk-common-themes, and so it would be helpful not to have to duplicate that data in other snaps.
As it stands at the moment a user can manually connect up the interfaces to two theme snaps, but that’s obviously not something we can recommend as the number of application snaps adding theme support grows.
So instead we get requests to add these themes to gtk-common-themes. I think there is definitely room to add some more, but we need to weigh this against the increased package size incurred by all users. It also means that theme authors need to rely on us to push out updates to their theme in a timely manner (including promoting releases from edge to stable). The sooner we can move beyond the single monolithic theme snap, the better.
If all is needed is just connecting all slots with the same given content label, to any plug requiring it, we could grow some snap-declaration plug/slot rules language syntax to enable that behavior that could be used on the store for all these theme flavaour snaps. We need to grow some language like this on the for plug side related to camera vs hotplug. But here we would need some language on the slot side.
I’m just curious where this discussion sits. I had an issue open to add the budgie themes into the “common” snap. Should I hold off on that? Or continue on?
We’re waiting for snapd to add support for greedy plugs. For example autoconnection of *:gtk-3-theme. I’d still prefer holding off adding too much as we won’t want to remove things later.
Hi Ken, I believe I had read a post regarding the sprint in Montreal in which new themes were added for Manjaro I believe? Are we now able to look at doing this for Ubuntu Budgie? I had added a request a few months ago (official) over at https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/10. Is that the proper place?