This doesn’t seem to be the case when I test it. When I use snap run --shell mattermost-desktop to look into those directories, I see the mounted ones, not the original ones. It seems to work just like a normal mount, hiding the original directory.
That is where we want to get to eventually, but don’t have the infrastructure in place yet. I mentioned the upcoming Snapcraft Templates feature a little further down in that section as a solution, which will allow the required interface definitions to be inserted automatically.
While that feature isn’t quite ready yet, I thought there was value in sharing details of how people can test our what we’ve got working right now.
At the moment this is just GTK 3. GTK 2 is more complicated due to the use of native code theme engines that need to match the GTK 2 build the application is using.
While you managed to get Communitheme working by packaging the pixbuf engine with your app, that wouldn’t be sufficient for e.g. Ubuntu’s Ambiance/Radiance themes that use the murrine engine.
We will probably look at dealing with GTK 2 themes in future (together with packaging the binary engines), but having third parties packaging their themes will likely require more review due to the fact that the theme engines can effectively do anything.
For Electron apps, it is worth considering moving forward to an Electron build that uses GTK 3, since that will be required for other upcoming desktop related features anyway.
1 Like
Ah, gotcha; that makes sense, and so this will just work later on. That will be good! Nice work.
Snapcraft Templates seems like a good way to go. In the meantime, can we add this support to the desktop helpers? It already has some support for themes, but using gtk-common-themes would make that more robust, support more themes and use less space.
Communitheme is gaining a lot of traction but isn’t supported by default by desktop-helpers, so many snaps look ugly and some are even broken. Including gtk-common-themes support in desktop-helpers will probably be the easiest way to fix as many snaps as soon as possible.
@kenvandine @didrocks, what do you think?
That’s not something we can do directly in the desktop-helpers. Each snap would need to be updated adding the yaml to connect the content interfaces. I’ve updated all the snaps maintained by the desktop team and they all work fine with communitheme. I just don’t have a way to update other people’s snaps and I don’t want to encourage too many people to add this boilerplate code in their yaml that will be harder to maintain in the future. It’s fine if they want to, but I don’t want to push people to do that.
1 Like
I think @galgalesh is suggesting that snapcraft-desktop-helpers pull in Communitheme manually so it gets included into the application snap.
I’d personally prefer not to do that: the whole point of the theme snap work was to recognise that no matter how many themes we bundle with an application snap, it will never be enough. And each bundled theme adds to the package size for every app the user installs. In contrast, with theme snaps we only transfer the theme data once, and can update the themes without requiring every application developer to rebuild their snaps.
2 Likes
I thought it would be possible to add the plugs to the desktop-helpers.
Since this isn’t possible, I still think desktop-helpers should pull the theme manually because communitheme will be included in Ubuntu 17.10. I’d like to do this as soon as possible so that most snaps support Communitheme when 17.10 lands.
To add something “noobish” to this conversation full of knowledge:
If gtk2 theming turns out to be really, absolutely impossible for snaps, there is one last thing that could be done as a backup plan b:
If it’s a Qt snap using the gtk2 theme via QGtkStyle then better use the native Qt skin then no skin. An example for this worst case is simplescreenrecorder which has no theme at all and ends up with no theme at all (grey).
Note that what I’ve documented in this thread is the primary system we want to use for making themes available to snap applications going forward: it isn’t a fallback for those not using Ubuntu.
Updating desktop-helpers would also require all application developers to rebuild their snaps, so isn’t obviously better. And with themes like Communitheme that are still under active development, it wouldn’t just be a single rebuild (compare with the content interface solution, where pushing out a new gtk-common-themes release updates all applications).
I agree that the currently required boilerplate is undesirable, which is why the Snapcraft developers are working on the new templates feature.
I don’t think handling GTK 2 themes would be impossible: they just have vastly different security considerations compared to GTK 3 themes (e.g. how do you know that a GTK 2 theme engine doesn’t embed a Bitcoin miner?).
As for Qt applications, any Qt 5 app should be able to use GTK 3 themes via the qgtk3 platform theme plugin. However, the simplescreenrecorder snap appears to have been built with Qt 4. Looking upstream it seems the application supports Qt 5, so rebuilding the snap would probably be the best option.
This shouldn’t be necessary now as $SNAP/share should be already prepended in XDG_DATA_DIRS since https://github.com/ubuntu/snapcraft-desktop-helpers/pull/121
It looks like there are some problems with picking the correct theme under Wayland.
Under Wayland, GTK selects its theme via the GSettings API. While the gsettings interface can give a snapped application access to the user’s configuration database (~/.config/dconf/user), it will be using a different set of GSettings schemas which can have different default values.
So on my laptop running Cosmic, I see the following:
$ gsettings get org.gnome.desktop.interface gtk-theme
'Yaru'
$ snap run --shell gnome-calculator
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ $SNAP/bin/desktop-launch gsettings get org.gnome.desktop.interface gtk-theme
'Ambiance'
… and sure enough, gnome-calculator displays using the Ambiance theme while everything else is using Yaru. This is not something that can be solved from within the snap, so we’ll probably need some extra support snapd side.
1 Like
If you don’t mind I would like to drop this section as the environment is already handled by the desktop-launch script as I previously mentioned.
I’ve implemented a demonstration snap with some improvements and also uses the desktop-gtk3 remote part:
This topic is now a wiki. Thanks!
1 Like
i made a content snap which basically packs qt5 runtime in it (desktop-qt5 dump), i made a consumer app and added slot of gtk-common-themes in it , my app launch just fine but won’t use theme. what’s wrong ?
It’s a bit hard to tell without more details. Can you tell if the app is running with the libqgtk3.so platform theme plugin?
here is link to seperate thread i have created:
This is a tutorial for getting system themes working with GTK+ 2 applications: https://snapcraft.io/docs/gtk2-applications
Is this what you are looking for, @knocte?