I saw a complaint this week about the Greybird theme not working with Snaps.
Greybird is the default theme for Xubuntu. Xubuntu includes snapd by default.
I propose that we include the themes that are shipped by default in official Ubuntu flavors in gtk-common-themes.
That’s sensible. Could you please file an issue for that on gitlab? https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes
Done (but not by me 
)
See also https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/merge_requests/9 and https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/8
Hi guys, I just picked up on this thread and would love to get our (Ubuntu Budgie) default theme in there. (Pocillo).
@kenvandine - I have also created an issue over at the common themes repo.
Thank you in advance, appreciate your time.
Why not have a gtk-<flavour>-themes that provided the same content interfaces?
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.
Since there’s also GTK theme for Breeze, having that would be awesome for consistency in Plasma desktop
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:
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?