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: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
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.