Running on up to date Neon testing, since a couple of days ago - after a restart - on Wayland locally install Gtk3 apps (also Flatpak, but I’m assuming its for the same reason) render really badly - without anti-aliasing (Plasma GTK theme preview):
This is the same app, running normally and then with WAYLAND_DISPLAY= override.
I tried all the reported fixes: install xdg-desktop-portal-gtk instead of xdg-desktop-portal-gnome; make sure ~/.xsettingsd has the correct Xft settings; check that font-config has the correct anti-aliasing setting
I’m not sure what else to check. Please advise.
kinfo:
Operating System: KDE neon Testing Edition
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.0
Kernel Version: 6.8.0-49-generic (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-12700H
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Good question - but no: this is all 100% scaling. In the office I have displays that are scaled at 125% but I haven’t been there since the issue started happening.
Hmm…just a thought, perhaps check and see what packages updated before that restart to see if anything jumps out as potentially related - ex. Plasma itself, or any xdg-desktop/portal related ones?
It sounds likely to be a software configuration change - looking back from Nov 26, the likely candidates (upgrades that have happened since then and sound possibly related are):
Reverting kde-style-breeze, breeze, breeze-cursor-theme, kwin-style-breeze, breeze-gtk-theme, xdg-desktop-portal, plasma-framework, kde-style-breeze, kde-config-gtk-style-preview, kde-config-gtk-style, xdg-desktop-portal-kde does fix the problem. Now to fine the specific package causing the issue - unfortunately this requires logging in and out multiple times
Update:
The problem is the update of xdg-desktop-portal from 1.18.4-1+24.04+noble+stable+build1 to 1.19.0-0zneon+24.04+noble+release+build11
Hmm, the xdg-desktop-portal one jumps out as that’s newer (1.19.0) than the version I’ve got on Fedora 41 (1.18.4) - that looks to be newer than the tagged release on their GitHub - GitHub - flatpak/xdg-desktop-portal: Desktop integration portal - though there may be totally legit reasons for that.
As I’m typing this, I can now see your update - hmm, yeah that’s an interesting one as not even Arch Linux is on that version yet…perhaps an upstream bug report might help?
I can see that 1.19.0 is tagged on Nov 28. I got the update from the Neon release channel on Nov 29. I’m surprised that Neon ships 1.19, as No Ubuntu version (not even 25.04 dev) ships 1.19.
Also the NEWS file for 1.19.0 is weird in that it does not include the changes for 1.18.2 through 1.18.4.
Reviewing the packaging changelog, it reports that 1.19.0 was pushed as an experimental development release, then picked up by Neon automated build.
Apparently I had GTK_USE_PORTAL=1 in my local configuration, but after unsetting it - it is still set on reboot, which makes sense - it is a useful setting that causes Firefox and SWT applications to use KDE file open/save dialogs, so its probably defined as a default in some package (I have yet to locate the guilty party).
After more analysis, I think the problem is that the desktop portal fallbacks aren’t handled properly - the xdg-desktop-portal daemon complains (in its service log) about portals.conf misconfiguration (even though I can see it opening the kde-portals.conf file and doesn’t seem to invoke the GTK portal at all. The 1.19.0 NEWS file has this entry:
The portals.conf parser is now able to handle fallback backends better, and respects the order of backends in the config file.
Which sounds to me like they changed something and now it is broken.
I added a report in the GitHub issue - we’ll see what gets out of that. After rebooting another time, the GTK_USE_PORTAL environment variable is no longer set - so it isn’t set by default on Neon and there was some weird thing going on on my system (likely the systemd user session didn’t close properly the previous time I tried to log out). So this is currently my workaround: no KDE file dialogs on native GTK applications (the portal is still used correctly for Flatpak and Snap apps, so I’m not missing a lot).
Awesome digging there - and yes, maybe one of the folks working on Neon can give some context around what I imagine was a change in 1.19.0 that might have fixed some other issue and required pulling in a pre-release version early?
An analogy I can think of is, the RPMFusion repositories for Fedora pushed the beta version of the Nvidia drivers to their regular release repository, I believe in large part because of the well-publicized security bug that A) impacted the major version that had been in use and B) wasn’t going to be patched in that major version by Nvidia.
Either way, this is great context to have for any other Neon users who come across the same challenge!
