After finishing the following upgrade and rebooting
xdg-desktop-portal (1.16.0-3 -> 1.18.0-2)
xdg-desktop-portal-gtk (1.14.1-1 -> 1.14.1-3)
xdg-desktop-portal-kde (5.27.8-1 -> 5.27.8-2)
Firefox tabs got bigger, the mouse cursor became large in all GTK apps, and font is not anti-aliased.
You only need one of those, not both. You’re on Plasma, so get rid of xdg-desktop-portal-gtk.
xdg-desktop-portal-gtk is needed by some GTK apps installed as Appimages and Flatpak to fix anti-aliasing and various problems on KDE Plasma, the one that shouldn’t be installed is xdg-desktop-portal-gnome.
After removing xdg-desktop-portal-gtk then rebooting, the issue is still persistent, for now only downgrading those 3 packages fixes it.
No, that’s what the desktop-agnostic xdg-desktop-portal is for, not xdg-desktop-portal-gtk.
That’s a whole other matter.
Perhaps mention it on the most recent Unstable Updates thread then. 
xdg-desktop-portal upgrade breaks GTK apps
After finishing the following upgrade and rebooting
xdg-desktop-portal (1.16.0-3 -> 1.18.0-2)
xdg-desktop-portal-gtk (1.14.1-1 -> 1.14.1-3)
xdg-desktop-portal-kde (5.27.8-1 -> 5.27.8-2)
Firefox tabs got bigger, the mouse cursor became large in all GTK apps, and font is not anti-aliased.
I tried removing xdg-desktop-portal-gtk, then rebooting, but the issue is still persistent, for now only downgrading those 3 packages fixes it.
I can not reproduce the issue.
$ pacman -Q | grep xdg-desktop
xdg-desktop-portal 1.18.0-2
xdg-desktop-portal-kde 5.27.8-2
I do not use xdg-desktop-portal-gtk in KDE Plasma Wayland.
Very old issue that for some reason needed to be explicitly addressed months ago even though no one should have mutliple portal frontends, and kde certainly shouldnt have the gtk version…
Though … your described issue should likely have nothing to do with the portal(s).
Also … why are you reposting?
Oh I see aragorn sorta told you to … but I doubt they meant come here with your portal assumptions.
You were already told to remove xdg-desktop-portal-gtk.
I told him to. 
Removing xdg-desktop-portal-gtk and rebooting doesn’t fix the problem.
You edited your post while I was still typing.
I blame it on the spacetime continuum. 
Because the portals are unrelated.
But downgrading those 3 portal packages fixes the problem.
Is this really true? Or is this an assumption for the portal requirement which does not need any particular backend? (thats how it usually works)
$ pacman -Si flatpak
Repository : extra
Name : flatpak
[...]
Depends On : appstream bubblewrap curl dbus fuse3 glib2 json-glib libarchive libmalcontent libseccomp libxau ostree polkit python systemd xdg-dbus-proxy
libostree-1.so=1-64 xdg-desktop-portal
[...]
Notice it depends on portal. No particular backend, though many unobservant users may end up believing that *portal-gtk is somehow required because its the first suggestion to fill the dep, though any can be used, and on kde it should be … *portal-kde.
And … it is probably worth noting if your ‘problem apps’ are these kinds of non-native format like Flatpaks, etc.
See https://github.com/flatpak/xdg-desktop-portal-gtk/issues/355
https://bugs.kde.org/show_bug.cgi?id=415933
My shown apps are all native.
Ah, so in the specific case of using Wayland+Flatpak+Gtk on a Non-gtk desktops an unresolved bug (now not considered a bug?) dictates using *-portal-gtk.
News to me.
But still only one will be used at a given time. And I have portal/portal-kde installed with no erroneous affect on gtk/FF … and you state that downgrading has an impact … I have to then assume its something to do with *portal-gtk and/or your environment (variables).
Multiple backends can be installed, and they are located in
/usr/share/xdg-desktop-portal/portals/*.portal. Each portal backend file contains a list of interfaces that it can handle, and the desktop environments that it can be used in. When a request is made,xdg-desktop-portalwill use theXDG_CURRENT_DESKTOPenvironment variable to determine which backend it will use for the request. If more than one backend can be used for the current desktop, the first one in alphabetical order is chosen. If no backend for the current desktop can handle the interface, no backend is available for the current desktop, orxdg-desktop-portalcan’t determine the current desktop, then it will choose the first portal in alphabetical order between all of the installed portals that support the requested interface.
I have to then assume its something to do with
*portal-gtkand/or your environment (variables).
You are right, I was using GTK_USE_PORTAL=1 to force all GTK apps to use KDE open/save dialogs, it worked fine before this upgrade and all GTK apps looked fine
It seems something changed in those new portal releases that broke GTK_USE_PORTAL=1 support.
Removing that variable fixes the problem, but GTK apps started to use that ugly GTK open/save dialogs.
I use that variable too (only on firefox) in order … to use the kde portal.
But here it has not had a negative affect - before or after recent unstable upgrade.
Fonts are also fine, but I dont use flatpak.
Stop. Has anyone actually looked at the upstream changes with 1.18.0 and the Arch package changes regarding it? No? Then please do that before recycling old information that may or may not have been ever accurate to begin with.
Well … what are those then if you know?
Maybe this?
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.
But its not really elaborated upon.
I suppose man portals.conf is where one would look …
For what its worth I created
~/.config/portals.conf
[preferred]
# Use xdg-desktop-portal-kde for every portal interface...
default=kde
But with only the one portal it may not have been necessary.
Folks with multiple on the other hand may wish to configure the file.
Are you sure it’s actually the GTK portal that they use? I am asking because I have noticed that some applications — e.g. telegram-desktop — have begun using the qt6 version of the portal instead of the qt5 version.
Now we have yet another thread …
https://forum.manjaro.org/t/xdg-desktop-portal-1-18-0-upgrade-issues/149026/11?u=cscs
