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
2 Likes
@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.
Some questions:
- 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â
1 Like
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 gtk-common-themes.
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.
2 Likes
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
