Bug 417441

*** Bug 417768 has been marked as a duplicate of this bug. ***

Can you be more specific? What application?

Anyway, you shouldn't be really using GTK_USE_PORTAL=1, it's not meant to be used outside Flatpak.

> Anyway, you shouldn't be really using GTK_USE_PORTAL=1, it's not meant to be used outside Flatpak.

Distros do that to make Firefox use a sane file dialog

(In reply to Kai Uwe Broulik from comment #3)
> > Anyway, you shouldn't be really using GTK_USE_PORTAL=1, it's not meant to be used outside Flatpak.
> 
> Distros do that to make Firefox use a sane file dialog

I know they use it for Firefox, it's just it has a side-effect and Firefox doesn't really behave the same  and expects it runs in the sandbox.

(In reply to Kai Uwe Broulik from comment #3)
> > Anyway, you shouldn't be really using GTK_USE_PORTAL=1, it's not meant to be used outside Flatpak.
> 
> Distros do that to make Firefox use a sane file dialog

Exactly, I use it globally so all apps that can (mostly FF, FF Nightly and Thunderbird), use KDE dialogs.

I can confirm this issue.
I use Breeze dark global theme but rhythmbox music player and fragments torrent client installed from flathub use light theme.

Operating System: Arch Linux 
KDE Plasma Version: 5.18.0
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1

My best guess is that this is because our GTK theme or whatever we apply to GTK apps is not able to read the configuration, because you tell it that the app is sandboxed and there is no support for Settings portal to make it bypass the limitation (even though there is none).

*** Bug 418016 has been marked as a duplicate of this bug. ***

(In reply to Patrick Silva from comment #6)
> I can confirm this issue.
> I use Breeze dark global theme but rhythmbox music player and fragments
> torrent client installed from flathub use light theme.
> 
> Operating System: Arch Linux 
> KDE Plasma Version: 5.18.0
> KDE Frameworks Version: 5.67.0
> Qt Version: 5.14.1

For apps from Flathub I suppose you have to install org.gtk.Gtk3theme.Breeze or org.gtk.Gtk3theme.Breeze-dark, depending which one you use in your system.

(In reply to Jan Grulich from comment #9)
> (In reply to Patrick Silva from comment #6)
> > I can confirm this issue.
> > I use Breeze dark global theme but rhythmbox music player and fragments
> > torrent client installed from flathub use light theme.
> > 
> > Operating System: Arch Linux 
> > KDE Plasma Version: 5.18.0
> > KDE Frameworks Version: 5.67.0
> > Qt Version: 5.14.1
> 
> For apps from Flathub I suppose you have to install org.gtk.Gtk3theme.Breeze
> or org.gtk.Gtk3theme.Breeze-dark, depending which one you use in your system.

Hmm, they seem to be quite outdated. I will try to update them.

(In reply to Jan Grulich from comment #9)
> For apps from Flathub I suppose you have to install org.gtk.Gtk3theme.Breeze
> or org.gtk.Gtk3theme.Breeze-dark, depending which one you use in your system.

both are already installed on my system.

(In reply to Patrick Silva from comment #11)
> (In reply to Jan Grulich from comment #9)
> > For apps from Flathub I suppose you have to install org.gtk.Gtk3theme.Breeze
> > or org.gtk.Gtk3theme.Breeze-dark, depending which one you use in your system.
> 
> both are already installed on my system.

They are outdated and built only for the old runtime so they will not work. I tried to update them, but I failed and I cannot afford to spend more time on that. You can open a bug in Flathub and see if anyone updates it or not.

(In reply to Jan Grulich from comment #12)
> They are outdated and built only for the old runtime so they will not work.
> I tried to update them, but I failed and I cannot afford to spend more time
> on that. You can open a bug in Flathub and see if anyone updates it or not.

Done.
https://github.com/flathub/flathub/issues/1384

As we can read in the bug report above, flatpaks need xsettingsd on Plasma.
However, kde-gtk-config does not update ~/.xsettingsd when theme settings are modified.

kde-gtk-config updates ~/.config/xsettingsd/xsettingsd.conf file, because xsettingsd seeks it's configuration in various places, not just home directory. It works for me on kde neon dev iso.

So you're saying this should already be fixed, then? I guess so because I can confirm that when xsettingsd is running, visual settings get picked up by Flatpak apps.

I can't reproduce the issue.

Can someone post detailed, step-by-step steps to reproduce after verifying that xsettingsd is installed and running?

In fact the color scheme of GTK3 apps installed via flatpak is not correctly updated. Furthermore, cursor is also incorrect (Adwaita instead of the one set in system settings), but this is another issue. I have this problem only on Wayland session. According to Ksysguard, xsettingsd is running on my Wayland session.

1. start Wayland session

2. set Global theme to Breeze in system settings > Global theme

3. set GTK3 theme to Breeze in system settings > Application Style >
Configure Gnome/GTK Application style

4. install the packages below from flathub:
flatpak install flathub org.gtk.Gtk3theme.Breeze
flatpak install flathub org.gtk.Gtk3theme.Breeze-Dark

5. install a GTK3 app from flathub. I installed fragments torrent client:
flatpak install flathub de.haeckerfelix.Fragments

6. open fragments (it uses Breeze GTK theme as expected)

7. close fragments

8. switch global theme from Breeze to Breeze Dark in system settings > global theme

9. open fragments again: it is still using Breeze GTK theme instead of Breeze Dark

10. restart Wayland session

11. open fragments: now it uses Breeze GTK theme as expected

On X11 fragments uses Breeze Dark GTK theme as expected
after the steps 8 and 9.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.18.80
KDE Frameworks Version: 5.68.0
Qt Version: 5.14.1

(In reply to Matej Mrenica from comment #0)
> SUMMARY
> ...and the font is not antialiased.

> ADDITIONAL INFORMATION
> On wayland

Already reported as bug 415933

Correcting step 11:
11. open fragments: now it uses Breeze DARK GTK theme as expected

Thanks for the info. Will look into that.

Created attachment 126808 [details]
screen recording, applying gtk3 themes on X11

Colors scheme is not correctly updated on X11 too.
Please watch the attached screen recording showing Rhythmbox and Fragments (both installed from flathub) and Nautilus (from ubuntu bionic repos) while I set GTK3 themes.
1. All apps respect Breeze dark theme;
2. flatpaks (Rhythmbox and Fragments) have light colors and Nautilus is dark after I set Breeze theme;
3. all apps have light colors after I set Default (Adwaita?) theme.

Result 2 is unexpected.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.18.80
KDE Frameworks Version: 5.69.0
Qt Version: 5.14.1

*** Bug 422064 has been marked as a duplicate of this bug. ***

Any progress on this?

Hello, everyone! I think that what both the OP and Patrick Silva are experiencing is that: they're using Plasma/Wayland, but somehow  GTK applications end up using the X11 backend. In that case the settings are not picked up correctly, indeed. Everything is fine instead in the common case of GTK applications running on top of the Wayland backend.

Probably GTK applications are forced to use the X11 backend because the GDK_BACKEND environment variable is explicitly set on their system. Could any of you confirm? Just open a terminal and type:

    echo $GDK_BACKEND

I'm going to look into that

The issue is that apps in Flatpak can read themes in ~/.themes/ but not in /usr/share/themes/.

A few interesting links:

1. https://github.com/flatpak/flatpak/issues/3445
2. https://github.com/flatpak/flatpak/pull/3247
3. https://github.com/flatpak/flatpak/issues/4896

TLDR: Flatpak apps should not be able to access themes from the system. If you think about it, the system could be rather old, but Flatpaks can be updated independently to newer and newer versions. If in the future something w.r.t. theming changes, for example as happened for GTK 3.20: https://developer-old.gnome.org/gtk3/3.24/ch32s10.html, then Flatpaks will access incompatible themes.

OTOH, the PR in the second link and the fact that themes in ~/.themes can already be read suggests that it isn't considere a big problem, so there's hope :)

Note: the issue I was having when using GDK_BACKEND=x11 is a different thing really, and is tracked at https://bugs.kde.org/show_bug.cgi?id=459468

Luca, do you know if this still relevant today with all your recent changes?