Firefox has already solved its problem without using GTK_USE_PORTAL Firefox KDE integrationFirefox - ArchWiki
Oh, you are right, old memory 
MOZ_DRM_DEVICE=/dev/dri/card0 MOZ_USE_XINPUT2=1
(on X11)
Sorry, my mistake. Threads are merged now.
Do not use GTK_USE_PORTAL=1 in the global variable environment for all apps.
You can customize some GTK apps for example: signal-desktop app shows wrong GTK dialog in KDE.
Copy /usr/share/applications/signal-desktop.desktop to ~/.local/share/applications/signal-desktop.desktop
Edit ~/.local/share/applications/signal-desktop.desktop to change
Exec=signal-desktop -- %u
to
Exec=env GTK_USE_PORTAL=1 signal-desktop -- %u
Done.
1 Like
To summarize the issue, this problem was effectively introduced by xdg-desktop-portal 1.18.0, as it was mentioned in the release note
Changes that might be relevant for distributors:
- Rework how portal implementations are loaded. This new, more robust system allows selecting specific backends for specific portals, and layering them when necessary. Platforms that provide portals implementation are encouraged to provide a suitable configuration file.
So on KDE, you must install xdg-desktop-portal, xdg-desktop-portal-kde and xdg-desktop-portal-gtk, the latest package is used as fallback for non-native GTK apps (Flatpaks, Appimagesā¦) to fix the problem related to antialiasing font and themes on KDE Plasma.
The fix of fallback order was already made by KDE and was backported to 5.27, if you need quick fix without waiting for the fix you simply edit /usr/share/xdg-desktop-portal/kde-portals.conf like the following:
[preferred]
default=kde
org.freedesktop.impl.portal.Settings=kde;gtk;
After rebooting, GTK_USE_PORTAL=1 will work again like it did before.
Edit: upgrading to xdg-desktop-portal-kde 5.27.8-3 fixes the issue.
1 Like
or dont edit a default system file and instead place it in ~/.config/portals.conf
Or you could run
systemctl daemon-reload && systemctl --user restart xdg-desktop-portal.service
1 Like
On Stable, I had xdg-desktop-portal-gtk installed on KDE Wayland and removed it as instructed here. Now my Breeze cursor whenever I hover over or am in a Firefox, Thunderbird, etc. GTK window, the cursor changes to Adwaita theme. Hovering over the desktop or Kate shows the correct Breeze cursor theme.
EDIT: reinstalling xdg-desktop-portal-gtk corrects issue.
As already gone over here ā¦ *portal--gtk shouldnt normally be required on Plasma.
In the case you are using GTK Appimages/Flatpaks (and maybe only on wayland?) then it may be necessary if only for theming and to āfix fontsā for some reason.
The newer configuration may also be taken into account, especially for those who have multiple portals.
ex:
[preferred]
# Use xdg-desktop-portal-gtk for every portal interface...
default=kde
# Or fall back to gtk
org.freedesktop.impl.portal.Settings=kde;gtk;
For general theming you may need to readdress the settings you use, like applying gtk theming in system settings.
Oh, and, I still agree people shouldnt be setting GTK_USE_PORTAL=1 globally, but instead added to modified .desktop files in ~/.local/share/applications.
1 Like
Maybe it is a Wayland issue? All packages on my system are from the repositories and I donāt have the GTK_USE_PORTAL=1 environment variable set, so I donāt knowā¦ So I reinstalled the GTK portal and am moving on for now. I thought I checked for GTK settings under Appearance but maybe I missed somethingā¦
Thanks for your response!
Doesnāt xdg-desktop-portal itself do just that? ā My understanding is that it provides a fallback mechanism while coexisting with either xdg-desktop-portal-kde|-gtk|-gnome (depending on which DE is used); but not coexistent with more than one simultaneously.
Unless, I got that fundamentally wrong.
https://man.archlinux.org/man/portals.conf.5
Snippet:
Each key in the group contains a semi-colon separated list of portal backend implementation, to be searched for an implementation of the requested interface, in the same order as specified in the configuration file. Additionally, the special values none and * can be used
For the code bit itself:
Which is apparently now in the package itself.
Yes, I wasnāt questioning your application; only if it was actually needed.
Edit:- I see, so the same will presumably work for Gnome, for example, gnome-portals.conf:
[preferred]
default=gnome
org.freedesktop.impl.portal.Settings=gnome;gtk;
For the benefit of passers-by this isnāt necessarily accurate; Iām simply extrapolating.
No longer needed in the latest xdg-desktop-portal-kde 5.27.8-8 package, as its already there
The other caveats still apply though - this seems to have only be needed for those using some combination of KDE, Wayland, GTK apps, Appimage/Flatpak ā¦ and possibly some other unknown ingredients.
(some reported the font problem affected native apps, whereas I could not reproduce it, at least not on X11)
Yes, I participated in one of those discussions. Workarounds in the wild seemed sometimes far-reaching. Cheers.
Flatpaks, Snaps and other sandboxed Linux formats provide a secure environment which isolates the whole running application from the rest of the system.
This is a good mechanism for security and making it easy to publish the latest app with all its needed libraries, but it complicates the application integration with the user desktop.
For example, a Flatpak GTK app will use its own Adwaita theme and not the currently GTK theme set in your desktop configuration. And the real fix is to install your GTK theme from Flathub then your app will detect it and uses it instead of Adwaita.
But not all the Flatpak problems are resolved with that fix, because sandboxed GTK apps require various pieces of GNOME infrastructure to run without issues, such as org.gnome.desktop.* GSettings schemas and the org.gnome.SessionManager and org.gnome.Screensaver D-Bus interfaces.
So the solution was to provide those missing features for sandboxed GTK apps via xdg-desktop-portal-gnome (provided by GNOME) on GNOME desktop and xdg-desktop-portal-gtk (provided by Flatpak) on non GNOME desktops, while xdg-desktop-portal-kde (provided by KDE project) provides a backend implementation for xdg-desktop-portal that is using Qt/KF5.
This is all theoretically true, but the praxis shows that a significant percentage of snap/flatpaks/appsimages are older versions (ergo not that secure) and are missing dependencies, which defeats the purpose.
Indeed, one of the reasons these packages exist is to consolidate dependencies; locking them to a certain version, if you will; to overcome the annoyance of missing dependencies over a wide spectrum of distributions.
Having up-to-date hardware, along with latest programming and packaging technologies easily accessible; while wearing rose coloured glasses; probably allows the luxury of forgetting that the playing field isnāt so level out in the wild.
Well, for now Flatpak is clearly more adopted, because it allows devs to distribute their apps easily and consistently and avoid the packaging chaos in Linux world, letting them focus on important tasks like testing and programming.
I should think any convenience for devs is moreover an artifact of user demand for easier software management, as Linux continues appealing to a wider demographic.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.