Created attachment 146682 [details] GTK look on wayland with GTK_USE_PORTAL=1 SUMMARY In order to have a KDE file chooser in Firefox and other GTK apps, we need to add GTK_USE_PORTAL=1 variable to our environmental variable (user or system-wide), or in /etc/profile.d/mozilla-common.sh However, this setting somehow makes many GTK apps looks ugly: some themeless look with bad font rendering, see the attached screenshot. Re-enabling GTK look in KDE settings didn't help. Gsettings had also correct theme parameters and yet it was all ignored. With a help of friends on Manjaro forum, we found out that GTK_USE_PORTAL=1 is at fault here. The problem is, when I disable GTK_USE_PORTAL, I need to add it to launcher commands of every GTK app instead. This is impractical and can be overwritten during app update. Also, why GTK_USE_PORTAL, which is for file chooser, influence GTK settings in Wayland? This has to be some bug that is fixable. This issue was present for many, many months now, so on Plasma 5.23 and now on 5.24. STEPS TO REPRODUCE 1. Create /etc/profile.d/mozilla-common.sh export MOZ_PLUGIN_PATH="/usr/lib/mozilla/plugins" export GTK_USE_PORTAL=1 This will make Firefox to use KDE file chooser, and I believe it also works for Gimp and other GTK apps. 2. Start Wayland Plasma session 3. Start GTK app like pamac or simply run a preview of a GTK theme in app GTK settings (this will also show a strage, ugly look). OBSERVED RESULT Instead, a set GTK theme, we see dark or light adwaita or themless look with pixelartig font rendering - see the attached screenshot. EXPECTED RESULT GTK apps should look as set in GTK apps settings, and GTK_USE_PORTAL=1 should not influence it at all. Operating System: Manjaro Linux KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.8-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530 By the way, this GTK_USE_PORTAL=1 should be in Plasma settings, not as an obscure text config in various places. Simply add "Use KDE file chooser for GTK applications" to GTK apps settings, but first fix the issue with Wayland. GTK look.
>GTK apps should look as set in GTK apps settings, and GTK_USE_PORTAL=1 should not influence it at all. Please report to GTK. We don't have any influence of what happens inside those applications
This isn't helpful. Since xdg-desktop-portal-kde is a kde product, and it influences KDE wayland session, GTK will response in the same way "we are not responsible for look of our products in non-GTK or non-Gnome environment and how Plasma products make them look like in Plasma environment". Besides, I had PLENTY of similar responses and often the first one blaming the other side was usually wrong and in the end, the solution was with the first submitted bug team. I'm not telling that it is now, I don't know, but playing "it's not our problem" is a detrimental behavior that helps no one, because in such cases, no one cares to take a look carefully. Additionally, because the issue happens in Plasma, and I'm a regular user, I can't provide any useful information about how Plasma handles it. If you can confirm this issue and evaluate that it is really something that is in GTK upstream, it's up to KDE developers to either find a solution to this on KDE side, or point out what is wrong in GTK upstream and why, because the casual user won't be treated seriously. I'm a hugely disappointed to find that attitude here as well. In that line of thinking, the whole GTK look in Plasma should be never really a KDE concern? Then who is concerned with it? GTK/Gnome team? They are the first not to care about different frameworks other than their own, and Plasma is the one that is inclusive and tries to make other frameworks to work well in Plasma, even if it's not always an easy task. Many other users reported that GTK_USE_PORTAL=1 messes up the GTK look in PLASMA WAYLAND SESSION. So maybe the problem is with Wayland on Plasma? Or maybe really something is messed up on GTK side, but KDE can find a workaround? There is a big talk about making Wayland usable - then why you dismiss the bug so quickly, without looking at it at all, just because this is about how GTK aps look in Plasma? This is also a component of Plasma, and GTK devs will surely not care about how their products look outside of Gnome.
xdg-desktop-portal-kde provides only the platform-specific dialogs like the open/save dialogs. It doesn't affect anything about the app itself. So David was correct; if setting GTK_USE_PORTAL=1 causes GTK apps to get messed up in their main UI (not the dialogs provided by xdg-desktop-portal-kde), then that's a bug in their app code, not in any KDE code. This has nothing to do with our styling of the app because your screenshot shows that the app is using Adwaita, not the Breeze GTK theme. So if you report this to GNOME and they say "we are not responsible for look of our products in non-GTK or non-Gnome environment and how Plasma products make them look like in Plasma environment". Then you can respond with: "The app is not being themed at all and is using standard Adwaita styling." FWIW I cannot reproduce the issue on Wayland with Gedit; setting GTK_USE_PORTAL=1 and then opening gedit with the Adwaita theme produces no weird text issues.
It seems not only I have this issue. Here is the topic on Manjaro forum that I started loosely to share the experiences with Plasma 5.24 which I found to be rather buggy (still, I'm confident that this is just a phase, because every time with new updates, things are smoothened out): https://forum.manjaro.org/t/plasma-5-24-0-is-buggy-in-my-heavy-modified-and-personalized-desktop/102058/5 Anyway, I got advices about the issue and in the end, it turned out that GTK_USE_PORTAL=1 was at fault. Interesting is, that someone says even that this is a known issue and yet, you Nate, know nothing about it. This means, this bug is known only in some circles, probably Arch/Manjaro users. I even hoped, that this bug gets tagged as duplicate and I will be following the initial bug report, because THIS IS NOT A NEW BUG - I noticed it months ago but didn't care to report it. Since this was so obvious, I assumed that lots of people will bug you about it. It looks I was mistaken. So far, the responses didn't give me high hopes. It's strange that no one submitted it. My guess is, this may be some Arch packaging issue - maybe some compilation flag or something like that. As to reporting this to Gnome/GTK team, I have no idea about their bug tracker. I tried to find it, but got no clear answers... Did I report it on Gnome gitlab page, do they have a dedicated bug tracker? Which part of GTK this would belong to? Submitting bugs to KDE is a very complicated and confusing matter. Doing it on GTK - I feel completely lost and don't know where to start.
The GTK bug tracker is here https://gitlab.gnome.org/GNOME/gtk/-/issues/ Side note: > I noticed it months ago but didn't care to report it. Since this was so obvious, I assumed that lots > of people will bug you about it. It's quite common for people to think that the bugs affecting them are so obvious that *someone* else must have noticed and started to work on a fix, but this is often not the case because the triggers for a bug--even a severe one--often depend quite heavily on one's setup. What settings you use, what environment variables are set (as in this case), which rendering backend is in use, what GPU hardware you have, what version of the graphics drivers and kernel you have, and so on. The list can seem endless. This is why it's a good idea to report every bug you encounter. Quite often, the developers have never seen it before and may be completely unaware that any users are experiencing it. Second side note: I searched through the entire KDE codebase and did not find a single piece of code that looks at the value of GTK_USE_PORTAL, so I feel even more confident in saying that this is a GTK or GNOME bug of some sort. KDE's codebase is quite literally totally ignorant of whether that option is set or not; we don't do anything different at all. So the difference must be coming from the GTK or GNOME side. Now it's possible that setting that variable triggers behavior in their code that then in turn triggers some other behavior in our code that causes the bug, but unfortunately there's no way for us to know this without either the GTK or GNOME developers telling us this, or one of us being able to reproduce the issue, which so far, we can't.
Thanks for the link. It's possible, that some outdated package that was excluded from repo or some old AUR package is causing this. This happens on Arch systems. Of course, a long time users as me, try to clean orphaned packages, update pacnew files, but when a lot of apps is installed, they pull various dependencies, they change over time, get moved between repos, renamed, abandoned, etc. It's not easy to keep track with all changes. For the most part it's fine, but at some points it can add unobvious variables that cause obscure bugs. I guess, I will have to sit and sift through apps and packages to see what can be cleaned up and compare installed packages with those from iso's. It's a time-consuming process, but it can tell us which packages are essential. I do that once a two or three years, maybe. This is why I can keep my system so long-running, even if I sometimes switch to unstable branch and install a lot of packages (system must be work ready for various range of tasks). Thanks for the help.
The short answer to this is: Install xdg-desktop-portal-gtk to fix this The detailed answer is: When GTK renders fonts it needs to decide whether or not to apply anti-aliasing. For this it reads some kind of setting. When using GTK_USE_PORTAL=1 it uses the org.freedesktop.portal.Settings portal. In particular it reads the key "org.gnome.desktop.interface:font-antialiasing". Now xdg-desktop-portal-kde doesn't know anything about Gnome settings and just returns an empty reply. GTK then proceeds to not apply anti-aliasing, which results in the broken fonts you are seeing. When installing xdg-desktop-portal-gtk there is now an additional portal backend to -kde (I didn't know portals could co-exist like that), and when asked about the anti-aliasing setting xdg-desktop-portal-gtk returns "grayscale", GTK applies that and fonts look proper. To me it sounds very questionable that GTK needs xdg-desktop-portal-gtk to have sensible behavior, but that needs discussion with GTK/portals upstream
See also https://github.com/flatpak/flatpak/issues/2861 https://github.com/flatpak/xdg-desktop-portal/issues/642 https://github.com/flatpak/xdg-desktop-portal-gtk/issues/355
*** This bug has been marked as a duplicate of bug 415933 ***
(In reply to Nicolas Fella from comment #8) > See also > https://github.com/flatpak/flatpak/issues/2861 > https://github.com/flatpak/xdg-desktop-portal/issues/642 > https://github.com/flatpak/xdg-desktop-portal-gtk/issues/355 Thanks Nicolas for the clarification.
(In reply to Nicolas Fella from comment #9) > > *** This bug has been marked as a duplicate of bug 415933 *** (In reply to Nicolas Fella from comment #7) > The short answer to this is: Install xdg-desktop-portal-gtk to fix this I installed it, and it really solved the issue on the Wayland, although the app - pamac-gtk comes from repo. Thanks!