Thanks for the status update. When Snap support for themes comes out, will all existing Snap packages get the improvement automatically, or will I have to repackage Polarr so that it will respect the user’s system theme? If I have to repackage, is this the thread I should be following so I’ll get notified when it’s time to rebuild the Snap?
Any News on GTK and QT Theme Support? Its the major reason why i don’t use snap often
Justification on asking for news:
Layouts landed in 2.32 (10th April) according to the snapd roadmap, I think the ‘improvements happening in the content interface’ is referring to ‘Auto install of content snap dependencies’? That latter feature also landed in 2.32. I’m sure I’ve seen some work on the forum for application themes but I don’t remember where and it should be linked to in this topic!
all the snaps below use the wrong theme
Name Version Rev
gnome-calculator 3.28.1 178
gnome-characters 3.28.2 101
gnome-logs 3.28.2 37
gnome-system-monitor 3.26.0 45
snap version
snap 2.32.9+18.04
snapd 2.32.9+18.04
series 16
ubuntu 18.04
kernel 4.15.0-23-generic
core version and revision
core 16-2.32.8 4650
Hi, I would like to know if there was some way to fix this as today ? Thanks
So, some time has passed now, and I’d still like to release a snap of Pick, especially since there have been new Ubuntu releases which I haven’t turned on the PPA for, but I’m still stymied at the same point: that I don’t want to release a version which doesn’t look like all the rest of my apps. So, is there now a way of shipping a Gtk app in a snap which will use the system theme, whatever that system theme is? (I don’t know if this is a @kenvandine question, or someone else; hi Ken if so :-))
Yes, this will work for themes that are bundled in gtk-common-themes but not arbitrary themes found on the internet yet. Please see the documentation and let me know if you have any questions.
I do, specifically “why doesn’t it work for me”
My snapcraft.yaml is ColourPicker/snap/snapcraft.yaml at app · stuartlangridge/ColourPicker · GitHub (and the whole project is there if you want to pull it and try building). When run, it doesn’t use the theme of my other windows, but some light-coloured theme with different window decorations. What might I need to do to make this work?
Your snap is using gtk-common-themes properly, whoever gtk-common-themes doesn’t contain the MATE themes yet. @Wimpress is working on that still. Your app is properly themed on disco for me.
aha! Thank you @kenvandine – confirmation there is great. And now I know who to pursue next
A simple way to check whether the GTK side is working is to run your app with the GTK_THEME
environment variable, and see whether it conforms to the named theme. For example:
GTK_THEME=Breeze pick-colour-picker
You can see the list of GTK themes currently in the package by checking /snap/gtk-common-themes/current/share/themes/
. We do plan to add some more common themes, but the end goal is to allow themes to be packaged independently. We’ve set up gtk-common-themes
to make this possible, but currently snapd won’t auto-connect additional theme snaps to application snaps.
And Pick is solely a snap now; much love to @popey, @kenvandine, and @jamesh for all the help on this! Go forth and choose colours and get cool names for them.
Why is it not possible to bundle additional themes as additional snaps? This is possible with flatpaks (there are many themes bundled as flatpaks, since quite a long time now). I find this “common themes” approach too restrictive. Are there any plans to fix this?
It is just work and associated complexity in both the store and the client. I believe nobody opposes fixing this in principle but nobody is tasked with making it work in the short term.
That is certainly the plan, and the way we’ve packaged gtk-common-themes
is intended to make this possible.
If you put together a snap that offers the same content interface slots as gtk-common-themes
, it is possible to install it alongside gtk-common-themes
and connect it up to the corresponding plugs on application snaps simultaneously (as well as the multi-user case, this is important for icon themes where you may want to package a theme that inherits from one published in the gtk-common-themes
snap).
What doesn’t work at the moment is:
- snapd won’t consider a plug to be a candidate for auto-connection if it is already connected to a slot. What we need is some way to mark the plug as “greedy”, wanting to connect to all matching slots, even if they are installed after the app.
- We don’t have a system in place to suggest or automatically download additional theme snaps if we detect the user has picked a non-default theme.
Putting together some test snaps for this is on my todo list. It just got shuffled to a bit of a lower priority because gtk-common-themes
turned out to be a 95% solution.
Thanks for the detailed explanation! Your priorities make sense to me and I’m in that 95%
I’m using overlay mount to enable theming on libreoffice snap. It works just fine! btw, Any news on this topic?
Is there any news on this?
I would like to snap a QT app - so would need access to Qt’s theming system without touching GTK