Hey snapd team,
We launched yesterday the communitheme snap, which is a way for the theme team to quickly deliver new version of their theme work (which will be the default theme soon) on existing ubuntu version.
Basically, when you
snap install communitheme on Ubuntu 18.04 LTS, you get a new session available in gdm starting your user session using that theme.
More detail info in https://didrocks.fr/2018/04/10/welcome-to-the-ubuntu-bionic-age-new-wip-ubuntu-theme-as-a-snap/.
However, the theme leaving in /snap/communitheme subdirectory, it of course works for all applications (we basically append the path to XDG_DATA_DIRS) but for snapped applications, getting an apparmor denial.
We expect this snap to be popular and not having it working with snaps may reflect badly in general. In less than 24h, some people already subscribed to the bug: https://github.com/ubuntu/gtk-communitheme/issues/325. The gtk snap applications just appear transparents, which will be the case in particular for all default applications we ship as snap on Ubuntu 18.04 LTS.
I think there are 2 things to discuss:
- the long term solution, which is to provide a way for snapd to autoconnect and detect themes living in various snaps. However, as we need to go to the design phase, user experience and implementation, I see this taking some time, and meanwhile, we might get the negative reports of snaps not working with this theme.
- maybe a short-live solution, as we are closed to 18.04 release? Do you think a temporary solution like https://github.com/didrocks/snapd/commit/f4952b12687133401b4f70a100383b98811ccd50 would be acceptable until we go on designing and working together on the long-term one? I know it’s a little bit against snapd principles to allow between snaps communication, however, if we look at the desktop interface already, it has some specifities like accessing an unity directory: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go#L72
@jamesh has been working on using content interfaces for themes. See Supporting desktop themes via the content interface
Thanks Ken! However, I don’t think this is fixing this use case:
So, basically, it gather a set of themes. However, communitheme is heavily evolving. One way would be to take regular snapshot, but it means that the theme will evolve at 2 speeds and not aligning between themes applied on the system level and the ones from the snap level. Any thought on this?
Also, it doesn’ t seem it’s shipping yet, does snapd have this default autoconnect feature in already?
Do you mean auto downloading of the providing snap? I’m not sure if that is in a released version yet, if not it will be real soon.
That could be a workaround, but we will thus have to upload regularly (like once a week) this snap to not deviate much from the communitheme snap. Do you think that’s acceptable? However, the content will deviate from the current “released” snap (not the same git commits and such), so it will make snap not using the same level of quality theme than the one in the deb using the official communitheme snap. Also, there will be no branch/edge/stable channel selection for it.
- I don’t find
gtk-common-themes yet on the snap store, any ETA for it to be uploaded?
- I guess most of our snaps (at least, the ones we install by default) will have a plug depending on this gtk3-theme/icon-theme slot, correct? Is it already the case?
- I would welcome an ETA for the auto downloading snap feature.
According to the snapd roadmap, it’s in snapd 2.32 (apparently released to stable yesterday-ish)?
Listed as: ‘Auto install of content snap dependencies’
While the access itself would be easy to add, it is against the design principle of snapd to do this (specifically, the communitheme snap should provide its theme as a content interface for other snaps to consume, not have the desktop interface that is provided by core expose access to other snaps). It seems like snaps (or theme libraries) would need to be patched to know about the non-standard /snap/communitheme location whereas exposing it as a proper content interface avoids that since the content is bind mounted into the snap’s runtime environment.
As @kenvandine mentioned, work is ongoing for a big ‘themes’ snap. I don’t have the status of that work, but in Budapest we specifically mentioned the communitheme snap as one of the themes to be included in that snap. You mention elsewhere that the theme is evolving fast but that isn’t a problem at all: snaps are designed to move as fast as the publisher wants so just update the communitheme within the big themes snap and everyone benefits.
Lastly, patching snapd isn’t going to be as fast as you desire (probably)-- 2.32 is desperately trying to make it through the SRU process and it has been delayed a long time. That means this is most likely 2.33 material, which I suspect the theme snap will be done way before that.
For these reasons, my opinion is -1 on this change to snapd. Instead, please focus on helping to make the big themes snap meet your needs. Do note, while I gave my opinion, if you feel strongly that patching snapd is the right thing to do, please escalate to @niemeyer (as snapd architect) who can decide the path forward.
Ok, I’ll try to check with @kenvandine so that we can include communitheme in that snap. We need as well to update all desktop snaps we ship to use those plugs (and add as well the sound-theme one).
Also, as we deliver per-commit update on the edge channel for CI (+ branch name, and manual stable release), it means that it’s going to get a lot of updates, which might be fine, just a warning that the users may have a lot of downloads if they don’t track the stable stable channel in particular.
In general, this “one big theme snap” solution is temporary, correct? I fear a lot of 3rd parties snaps won’t have those specific plugs declared though, and will result in “transparent windows” if the user set a theme that isn’t available in one of those theme snap (or simply not connected), which isn’t a good experience. Is there anything planned to have a snap installed corresponding to current user selected theme, and switch the connection when the user switch to another theme?
Thanks to the help of @kenvandine and @jamesh, we got communitheme added to
This is the snap which will connect via the content interface to other snap applications. It declares 3 content type: gtk-themes, icon-themes and now sound-themes.
We align the content so that:
@kenvandine will update our default application GNOME snaps to plug to those 3 content interface so that gtk-common-themes will be available for those snaps.
Note that the bigger issue (due to lack of generic snap theme support) is that any application snap not declaring those 3 content interface will still have a transparent UI rendering if the user set a theme isn’t a platform one. Also, 3rd parties themes isn’t supported until there is a corresponding theme snap that the user currently manually connect.
Thank you for the work on this topic. Really looking forward to having my snap apps themed with the community theme.
Nevertheless, 3rd parties themes are a commonly used tweak, so its broken functionality is still a problem in my opinion. Is there a way of setting a “fall-back” theme in the snaps? If not, what will happen with third-party themes and snap apps?
This is why I think we need a longer term solution where snapd is aware of theme selected by the users, connecting the correct selection matching snaps automatically for the users. A gotcha is that connection are system-wide whereas theme selection is per-user (and it can be set by different means on various DE).
I wasn’t involved in the discussion with the snapd team but @kenvandine and @jamesh were AFAIK.
I’m interested in how this works. If I install this snap, can I apply the theme to my Xfce desktop like I can with a theme in a deb package?
@ali1234: we are talking here about only other snap application support. For that, you need other snap application to declare the correct plug and default provider for this big theme snap to auconnect to it.
Is there any way I can trigger a rebuild of
gtk-common-themes? I suspect many theme authors will want to do this themselves when they release a new version of their theme.
This would be very nice indeed.
I just removed the LO deb version and successfully installed the canonical provided LO snap to get the new 6.1 version
Sadly, it still uses a version of yaru which must be several months old (I see this because of the context menu styling )
It would be great if you could trigger the update soon, and also give us the possibility to trigger the updates ourselves. @kenvandine