Apps are not aware of desktop themes

[garrett]

Apps running via Flatpak do not respect the desktop's theme settings.

Affected scenarios:

• running a GNOME Flatpak app on non-GNOME desktop
• running a KDE Flatpak app on GNOME (usually Qt / KDE apps get restyled to look like GTK+)
• distros that use custom desktops (Ubuntu, Elementary)
• theme and icon set changed in gnome-tweak-tool
• theme changed in KDE

[alexlarsson]

This is somewhat tricky, because apps and runtimes can have different toolkit versions that the host, and themes are version specific. So, the theme you have installed may not necessarily work with the app.

Also, its generally hard to use themes (of various kinds) that are system installed (i.e. are in /usr) because those are not visible in the sandbox (/usr there is from the runtime). If you installed the themes in your homedirectory, and the app had access to the homedir, and the theme works with your app then it should work.

[aditiapratama]

if we can put our themes in $HOME/.var/app that would be easier. Below is my current inkscape from flatpak run on xfce DE

[alexlarsson]

I have some ideas how to do this nicely with extension directories, but I will have to think about it a bit.
Basically it would involve extensions that are not actually distributed as ostree trees, but instead just a directory with the right name in the right place. Then one could just drop files there. This seems useful for themes, but can also be used for other things, like plugins, GL drivers, etc.

[magcius]

Inkscape also can't access my system fonts. I can't figure out any way to install fonts in a Flatpak.

[alexlarsson]

@magcius That is weird, both the user and the system fonts should be in /run/host/fonts and /run/host/user-fonts. And the runtime fontconfig is configured to look there.

Is inkscape not using fontconfig?

[magcius]

Hm, indeed. I'll see if I can investigate.

[ikeydoherty]

What's the progress on this front? A lack of integration is certainly a blocker, as Flatpak apps look entirely alien

[ikeydoherty]

Food for thought: What if we have a single runtime bundle that contains /usr/share/themes, with multiple versions for the very well known themes out there? Could be my first runtime.. ^^

[alexlarsson]

I haven't really thought about it recently. Themes are a complex issue, as they generally are tied to very specific versions of the toolkits. For instance, flatpak already exports the host fonts because doing so is generally safe. But say a host-installed gtk theme works only against a particular set of gtk versions, so we can't generically export it to the app. Some themes are even .so:s so are very particular about versions.

What I think could work is having each individual runtime or application that ships a specific version of a toolkit could somehow request via an extension point themes for that particular version.

Unfortunately the layout of /usr/share/themes is not ideal for this, as it has the theme name before the "what is the theme for". I.e. if it was /usr/share/themes/gtk+-3.0/themename, then we could have an extension point at /usr/share/themes/gtk+-3.0 such that any extensions matching it would create a subdirectory in there.

[matthiasclasen]

If you look at https://git.gnome.org/browse/gtk+/tree/gtk/gtkcssprovider.c#n1925 we are looking at versioned directories. But of course, there are very few (if any) themes that ship those versioned variants.

…

On Thu, Jan 19, 2017 at 4:55 AM, Alexander Larsson ***@***.*** > wrote: I haven't really thought about it recently. Themes are a complex issue, as they generally are tied to very specific versions of the toolkits. For instance, flatpak already exports the host fonts because doing so is generally safe. But say a host-installed gtk theme works only against a particular set of gtk versions, so we can't generically export it to the app. Some themes are even .so:s so are very particular about versions. What I think could work is having each individual runtime or application that ships a specific version of a toolkit could somehow request via an extension point themes for that particular version. Unfortunately the layout of /usr/share/themes is not ideal for this, as it has the theme name before the "what is the theme for". I.e. if it was /usr/share/themes/gtk+-3.0/themename, then we could have an extension point at /usr/share/themes/gtk+-3.0 such that any extensions matching it would create a subdirectory in there. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEnGHap0GK_wKbHEgg7732SPTdC8myrHks5rTzMHgaJpZM4I1Jl-> .

[alexlarsson]

Yes, we can use versioned directories, or we can match the extension on versions. For example, we could have an subdirectory extension point called something like org.gtk.theme3_22 and then if you have org.gtk.theme3_22.Adwaita installed then it would be mounted at $extensionpointdir/Adwaita. However, as I said, that unfortunately doesn't match the themes directory layout...

[matthiasclasen]

oh, you're saying the problem is that its .../Adwaita/.../ 3.22 ... and not .... 3.22 ... /Awaita/... yes. thats unfortunate.

…

On Thu, Jan 19, 2017 at 5:09 AM, Alexander Larsson ***@***.*** > wrote: Yes, we can use versioned directories, or we can match the extension on versions. For example, we could have an subdirectory extension point called something like org.gtk.theme3_22 and then if you have org.gtk.theme3_22.Adwaita installed then it would be mounted at $extensionpointdir/Adwaita. However, as I said, that unfortunately doesn't match the themes directory layout... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEnGHRKj-AdML9izp9mlD1CyxmteODV2ks5rTzZpgaJpZM4I1Jl-> .

[alexlarsson]

No, not quite. The problem is that it is Themes/Adwaita/Gtk, and not Themes/Gtk/Adwaita. With the later we could make Themes/Gtk a subdir-style extension point matching a particular gtk version. But with the previous we can only make Themes an extension point, and the extension for Adwaita has to contain all types of themes, which makes it hard to match it to a particular version of the toolkit.

[alexlarsson]

Well, your point is true too.

[alexlarsson]

We could add a new type of extension point, which is similar to the subdir one, but lets you place the variable part in a different place than at the end.

For example, we might have:

[Extension org.gtk.Theme.Version322]
directory=lib/themes/$name
subdirectories=true
subdirectory-prefix=gtk-3.0

Which if you had org.gtk.Theme.Version322.Adwaita installed would mount it on lib/themes/Adwaita/gtk-3.0 (whereas without the subdirectory-prefix it would mount it on lib/themes/Adwaita which is clearly not ideal.

In such a setup we you could have both org.gtk.Theme.Version322.Adwaita and org.gtk.Theme.Version320.Adwaita installed, and only the one matching the extension point in the runtime would be used.

Does that make sense?

[alexlarsson]

Uhm, sorry, it should be subdirectory-suffix i guess.

[alexlarsson]

Also, this combined with the unmaintained extensions should let a distro ship a bunch of themes in /var/lib/flatpak/extension to integrate with flatpak.

[ikeydoherty]

Does seem reasonable.

[ikeydoherty]

Ya now I think more about it, this is always gonna be an issue of curation. Why would we offer the ability to expose "broken" themes, when we could make curated/tested extensions available instead.. ^^

[alexlarsson]

Well, curation is a policy thing, this is mainly talking about the technical implementation. I think what you want is the ability to inject themes into 3rd party apps in a targeted way (so you know gtk 3.20 apps get a 3.20 theme). Now, you might want to control exactly which themes are injected, but some other random user wants to inject his favourite theme (and the app author may not want custom themes at all...).

As long as this is possilble the distro/user can handle the curation.

[ikeydoherty]

Currently bindmounting themes directory seems to work fine, but ofc as you say, picking the right one to make available is key. I think in terms of larger umbrella there needs to be a simple cascade to determine the "right" asset to make available, same for the icon theme.

[Anti-Ultimate]

Isn't GTK supposed to be stable since GNOME 3.20 ? From my experience with AppImages, themes in applications broke before GTK 3.20, but it's never happened since. Ideally, you could mount the theme directory the user has the DE to use, and if it's not compatible, default to Adwaita / the default theme.

[jbicha]

By the way, if I am using Adwaita and I have Global Dark Theme enabled, Flatpak apps just use Adwaita and ignore the Global Dark Theme setting.

[mdickie]

So the key could be to distribute themes through Flatpak.

[matthiasclasen]

The 'global dark theme' is and has always been a hack. The dark-theme settings is a per-application setting.

[alex285]

@matthiasclasen there is a different bug in that, to reproduce

1. Set dark theme for example on Feedreader
   /.var/app/org.gnome.FeedReader/config/gtk-3.0/settings.ini

gtk-application-prefer-dark-theme=1

2. Open Feedreader. Adwaita Dark theme works

3. From Tweak Tool set another theme, for example Arc

4. Now open again Feed Reader

Output
Feedreader will now use Adwaita Light

so that flag will work only if the global theme is set to Adwaita. except if there is another way to set dark variant per app

[phw]

@alex285 While this is very annoying and also applies if prefer dark theme is set on a per application basis, I think this is a separate issue, likely a GTK issue and not Flatpak related (even though Flatpak makes the issue obvious)

[alex285]

@phw i dont know how to set that flag per app for nonFlat apps, so i cannot test if it doesn't work there either :/

[matthiasclasen]

If we wanted to have a global dark theme, the most straightforward way to achieve that is to just have a DarkAdwaita theme, and totally ignore the prefer-dark setting.

[hadess]

I've locked the conversation as we're not covering new ground in the comments. You can still subscribe or, even better, provide Pull Requests if this problem is high up on your priority list.

[alexlarsson]

I have added support for what was mentioned in #114 (comment) (that is subdirectory-suffix=foo) in 5e1d456, which is now in the latest stable release.

I think the way forward here is for the gnome runtime to expose a org.gtk.theme.322 or suchlike, and then package the themes using flatpak. (Alternatively an unmaintained extension can be used if you just want to expose some local files, but that seems less usable for regular users.)

[matthiasclasen]

Here is a patch for gnome-sdk-images that adds such an extension and a shell script to populate it.

0001-Add-a-gtk-theme-extension.patch.txt

[matthiasclasen]

Some things still to consider before merging this:

• I don't think we need the detailed version information in there, since gtk3 is stable now, so we could simplify the name to org.gtk3.Theme.
• Symlinking the theme assets and css in place did not work, since it just puts the symlink into the sandbox as-is. Is the idea with unmaintained extensions to copy everything ? That works ok here, but I am wondering about big icon themes
• We need the same kind of extension for icon themes, including a similar script
• Who is responsible for running these scripts, and at what time ?

[matthiasclasen]

I've tried to create a similar extension for icon themes:

[Extension org.freedesktop.Icons]
directory=share/icons
subdirectories=true

The problem with this is that it covers up the existing icon themes in the runtime: Adwaita, HighContrast and hicolor. And merge-dirs seems to work only between extensions, not between extensions and the runtime.

[matthiasclasen]

I guess one way around the covering proplem would be to break out the currently included icon themes into (maintained) extensions of their own. Alex, does that sound like the right way forward ?

[alexlarsson]

I think in general having maintained themes is a better approach than messing around with copying things.
We can just put a bunch of the most common gtk3 themes on flathub.

For icon themes the we really need some basic icon theme to be installed, or a lot of stuff will not work. But, we don't want to make the icon theme extension auto-download, because then we will download all icon themes from the same repo.

I wonder if we could instead set XDG_DATA_DIRS so that we get another "layer" of directories where we look for things like icon themes.

[alexlarsson]

Currently we pick up XDG_DATA_DIRS=/app/share:/usr/share as the default fallback. But if we add XDG_DATA_DIRS=/app/share:/usr/share:/usr/share/runtime/extra-share or something we can put an extension point in /usr/share/runtime/extra-share/icons

[matthiasclasen]

Another go at defining the right extensions

https://git.gnome.org/browse/gnome-sdk-images/log/?h=theme-extensions

Couldn't quite figure out how to build a working extensions that matches one of these though...

[alexlarsson]

I added your icon theme spec to the fd.o base:
flatpak/freedesktop-sdk-images@aa5c4e9
(but with version 1.0 as icon themes are cross-runtime compatible.)

Here is an example icon theme: https://gist.github.com/alexlarsson/c0f60483ce883f61d28f7c3831b8d746

Will take a look at the Gtk side too.

I guess we can package the most common icon themes in flathub.

[alexlarsson]

Added gtk3 theme and icon themes to gnome sdk:
https://git.gnome.org/browse/gnome-sdk-images/commit/?h=gnome-3-24&id=6702c2bd1b652f3a183fc52fa3f92cfc41812efe

[TingPing]

This can be closed since we have theme extensions now.