Use the system gtk theme

sil 2017-05-06 22:33:07 UTC #1

I’ve packaged up a piece of gnome software as a snap. However, when that snap is installed and run, it seems to be using some sort of light theme which is not the theme that my desktop is using, which means that my app looks weird and out of place and unlike everything else on the desktop, which means that I don’t want to use it. Is this intentional? Or is there some snap configuration option that I need to turn on to make my app match everything else? (And if so, why isn’t it already on?) I did see that mvo has “themes” as a part of a bullet point to look at working on next; if this issue is entirely unaddressed up to now then I’m happy to come back when it’s sorted.

Theme for Gnome applications

Ubuntu Desktop Team Priorities

Call for testing: Mailspring

sergiusens 2017-05-07 08:34:17 UTC #2

You might want to ask for an update since it seems to have been a proposed discussion topic Next discussion topics

That said, to this date I don’t think it is supported but as you can see, there are plans for it.

zyga 2017-05-08 07:22:05 UTC #3

To explain what’s going on quickly. The snap execution environment doesn’t contain any of the themes you may have on your system (stock themes or any locally installed themes). Some snapcraft parts slightly work around that by bundling the same theme many people use on Ubuntu into the snap itself.

Sharing themes from the host into the snap is complex as there are API/ABI issues due to the way themes are made. I’m sure we could try sharing something as an experiment but it’s not guaranteed to work.

sil 2017-05-08 08:13:43 UTC #4

Honestly, this rather dooms the idea that a snap is a cross-platform way of distributing desktop software. Even if we ignore people who install external themes as being an edge case, simply looking at the idea of Ubuntu with Ambience, Ubuntu with Radiance, and Fedora will mean that my app will look out of place on at least one and probably two out of those three. That’s a terrible experience, I’m afraid; I am extremely loath to distribute my app this way and thus guarantee that it looks wrong on people’s desktops.

zyga 2017-05-08 08:16:01 UTC #5

As flatpak has the exact same problem the outcome may be some sanity towards how themes are defined. Maybe the ABI won’t be so variable or maybe the CSS declarations won’t change with every minor release number.

sil 2017-05-08 10:22:08 UTC #6

Yeah, I am loath to make a flatpak for exactly the same reason. Is your thought that the ABI and CSS for themes gets changed to be more stable, and then snappy can provide a way to pick up the system theme because it doesn’t change every go, and then I can make a snap of my app which will inherit the system theme? That could take some time…

zyga 2017-05-08 10:40:41 UTC #7

I mean we could offer an interface to get access to system themes (user themes are more complex but perhaps could be done as well) but there’s no guarantee that they can be even dlopen’d correctly. No guarantee that those use the same libc.

sergiusens 2017-05-24 18:21:37 UTC #8

GTK3 I’ve been told is pure CSS, so ABI should be fine as long as API doesn’t break across releases

zyga 2017-05-24 18:31:42 UTC #9

It does, constantly, so it’s still an issue. One thing we could do instead is to offer theme snaps that are appropriate for a given base snap or given shared runtime snap, somewhat akin to what flatpak is doing now. Then we could provide one that fits the right theme (via hooks).

ryanleesipes 2017-05-24 18:33:47 UTC #10

I agree with this. We can’t expose the place where themes are kept to the Snaps? I guess I’m not very knowledgeable as to how this works. But it’s actually a big deal for folks I convert to Snaps.

sergiusens 2017-05-24 19:51:37 UTC #11

Personally I don’'t mind this anymore. In a world where the CSS of apps open in my browser tab do not match my theme and there are less and less apps which are replaced by these, the eclectic spread of presentation layers feels ok.

ryanleesipes 2017-05-24 21:38:46 UTC #12

Some people use themes for things other than aesthetic preference (not me). For instance, some themes, fonts, and cursors help with accessibility. I think ultimately this needs to be solved. Whether that is through a Free Desktop standard or some other method.

willcooke 2017-06-20 18:23:06 UTC #13

The fix for accessing the dark variant theme is addressed in this commit:

Gocarlos 2017-08-19 15:20:32 UTC #14

Is it now possible to use the system theme or is this still not solved?
I’ve packaged the krop tool: https://github.com/gocarlos/krop

Though the app still looks pretty old, is there a way to make it look like the other apps installed on the system?
It uses currently qt4 with python.

Update on theme support

zyga 2017-08-19 19:23:56 UTC #15

It is not possible to use system theme yet. At least not in a general way. This will require substantial work to be robust and seamless. On the upside we are working on implementing this:

snapd will be able to figure out properties of the system / user it is running on:
one such property is the theme the user is operating
snapd will be able to automatically download and manage extension snaps such as opengl drivers or themes
such extension will be downloaded for each ABI that is needed by the apps on the system in case various base snaps and various different ABIs are in use
snapd will automatically use such extension snaps when certain interfaces are in use

Syntist 2017-08-31 15:41:09 UTC #16

Any update on this topic?

zyga 2017-09-04 06:46:08 UTC #17

Some, there’s ongoing work to generalize the mechanism in which snapd downloads additional snaps (“dependencies” for lack of a better term). With that in place we can extend it to themes. There’s a lot of ongoing work on extending the apparmor rules to allow access to fonds and themes. Some of those are also in the core snap, in the place of placeholder directories for mount points. We haven’t connected the dots yet as we’re working on some key features that will extend our ability to express mount profiles more freely than possible today. Last Friday a small security review were performed and direction and security coordination plan was set in place. This was a long standing desire to decide how to extend those tricky and security-sensitive places in snapd. With that set I’m now working on addressing the key security points (mainly environment scrubbing and child apparmor profiles for snap-update-ns) and my plan is to land those changes after 2.28 is branched off master for release. In 2.29 we should see first concrete elements, such as font sharing and improved ability to shape the mount namespace.

dies 2017-09-04 19:09:54 UTC #18

As I already wrote on bugtracker: How about checking what GTK version using .snap and what GTK version using user, then if this versions equal - system specific theme applies to snap?

niemeyer 2017-09-04 19:23:27 UTC #19

Yeah, there’s definitely good work coming into the theme support end. I haven’t had enough conversations with the desktop team to feel confident we have a solution to implement in hands, but I’m hoping we can move these conversations forward in the coming days.

Syntist 2017-09-05 08:26:43 UTC #20

So you are saying snap will installed the required theme, by checking the system theme? Nice

but what about qt, to get gnome and qt apps to look same, QGnomePlatform is use, though there isn’t much theme that support QGnomePlatoform but will you support it?

for now there are only one theme, adwaita-qt.

Edited: What if we mount the theme folder (/usr/share/themes and /home/$user/.themes) and For Icons (/usr/share/icons and /home/$USER/.icons)? It can save the one from downloading multiple copies of theme in future.

qt to use gnome theme is done by this guy, adwaita-qt and qgnomeplatform