Wayland GTK Flatpaks do not antialias fonts when run on KDE Plasma Wayland

[GuiltyDoggy]

Seems that 1.10.0 may have broken GTK Wayland Flatpaks when run in KDE Plasma Wayland. Fonts are blocky (not anti-aliased). See the following:

https://www.reddit.com/r/kde/comments/pzq1nc/this_week_in_kde_getting_plasma_523_ready_for/hf4ixvg/

https://discussion.fedoraproject.org/t/logout-login-bugs-in-plasma-wayland-should-i-be-using-x11/33226/7

Running on Fedora 35 Kinoite
KDE Plasma 5.22.5
xdg-desktop-portal-gtk-1.10.0-1.fc35.x86_64

[GuiltyDoggy]

Replacing with xdg-desktop-portal-gnome appears to be the solution

[pizzadude]

Installing xdg-desktop-portal-gnome and rebooting fixed it for me also.

[mcatanzaro]

I would reopen this because it's a valid bug report. We disabled the settings and appchooser portals, and need to bring them back.

[smcv]

We disabled the settings and appchooser portals, and need to bring them back

"We" here is whatever distributor is packaging x-d-p-gtk, more than x-d-p-gtk itself - but getting this fixed properly is probably going to need some upstream coordination, at least.

xdg-desktop-portal might well need some concept of a preferred backend and a fallback backend, so that it can prefer -gnome > -gtk when running on GNOME (assuming the -gnome backend's settings and appchooser portals are strictly better for GNOME users than the -gtk implementations). At the moment the -gnome and -gtk backends are both UseIn=gnome.

[mcatanzaro]

"We" here is whatever distributor is packaging x-d-p-gtk, more than x-d-p-gtk itself - but getting this fixed properly is probably going to need some upstream coordination, at least.

Well, this change was made upstream by changing the defaults in configure.ac, so it should be fixed upstream.

But yes, Fedora is manually passing configure flags to disable these portals downstream, and so will need to be fixed separately. We have a downstream bug report for that. I haven't checked what you did in Debian.

Ideally, we would remove all of these flags and just do the right thing. I don't see any reason why the set of portals to be installed should be configurable, unless some portals have optional dependencies....

xdg-desktop-portal might well need some concept of a preferred backend and a fallback backend, so that it can prefer -gnome > -gtk when running on GNOME (assuming the -gnome backend's settings and appchooser portals are strictly better for GNOME users than the -gtk implementations). At the moment the -gnome and -gtk backends are both UseIn=gnome.

Indeed.

In the case of the settings portal, might be less fragile if we were to somehow merge settings from both backends. That might be hard, though. I worry that having one backend that is used in GNOME and another used elsewhere, kept in separate repos, is going to inevitably result in bugs being fixed in one place and not the other....

[smcv]

I haven't checked what you did in Debian

For now, we're still enabling everything in -gtk (and treating it as both the GNOME and non-GNOME-GTK implementation, as in earlier releases) because -gnome is still waiting for legal review from the archive administrators.

[smcv]

I don't see any reason why the set of portals to be installed should be configurable, unless some portals have optional dependencies....

My understanding is that it's intended as a transitional mechanism, so that distros like Debian that don't have the -gnome backend yet can continue to build the GNOME-specific features into the -gtk backend.

[vchernin]

For now, we're still enabling everything in -gtk (and treating it as both the GNOME and non-GNOME-GTK implementation, as in earlier releases)

I also noticed the same thing with Arch, only -gtk is present currently. But I'm not the maintainer there so I don't know their plans.

[Erick555]

That might be hard, though. I worry that having one backend that is used in GNOME and another used elsewhere, kept in separate repos, is going to inevitably result in bugs being fixed in one place and not the other

Maybe -gtk backend should be depreciated then everyone would gradually transit to -gnome backend and use it the same as they used -gtk before. This would keep the status quo from user POV before -gnome was introduced. That would avoid code duplication between two projects in long term.

[smcv]

Maybe -gtk backend should be depreciated then everyone would gradually transit to -gnome backend

If that was good enough, then there would have been no point in having the -gnome backend as a separate project; the -gtk backend would have just changed its code (maybe in a branch).

As I understand it, the point of splitting them is that historically, half of the -gtk backend was equally applicable to GNOME and all other GTK-based desktops such as XFCE (and also as a portal backend of last resort for people who don't use a supported desktop environment at all but do have GTK installed), whereas the other half was specific to GNOME Shell and other purely GNOME components. The intention is that -gtk keeps the parts that are equally applicable to multiple desktops, and -gnome takes over the GNOME-specific parts. People who don't use GNOME shouldn't install the -gnome backend, and shouldn't need to install it.

For the Settings portal, obviously that hasn't entirely gone as intended.

[Erick555]

The intention is that -gtk keeps the parts that are equally applicable to multiple desktops, and -gnome takes over the GNOME-specific parts. People who don't use GNOME shouldn't install the -gnome backend, and shouldn't need to install it.

Originally I thought the same but now I see that -gnome took also non-GNOME-specific parts like settings and appchooser which mean -gtk is redundant as both gnome and non-gnome users can settle with -gnome. It's no like someone is going to pay for unused features the backend has.

Depreciation of -gtk at least save time for maintaining two projects instead of one and prevent users confusion about which one portal they're supposed to install (which changes depending on DE and distro). While I agree this makes the split pointless but I think the downsides of it are worse than benefits(?) as seen in discussion.

[mcatanzaro]

We just need to reenable settings and appchooser here. They'll have to coexist.

[Erick555]

Does -gtk have something that -gnome doesn't?

[mcatanzaro]

The point is that with these portals disabled, it will no longer depend on installing GNOME desktop components like gnome-settings-daemon. This was intended to be friendly to people using GTK apps outside GNOME.

[Erick555]

It doesn't depend on gnome-settings-daemon since some functionality was moved to gsettings-desktop-schemas (and it's only build-dep in fedora). IIRC it was even you who helped doing that so I don't understand what you are saying here.

With all portals disabled -gtk is just useless (as proven here) so the fact it saves you from installing some deps doesn't help.

[vchernin]

FYI Arch now has -gtk and -gnome, seemingly with default build options. So it would probably be good to reenable settings and appchooser upstream.