Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
GuiltyDoggy opened this issue Oct 2, 2021 · 16 comments · Fixed by #362
Closed

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

GuiltyDoggy opened this issue Oct 2, 2021 · 16 comments · Fixed by #362

Comments

@GuiltyDoggy
Copy link

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
Copy link
Author

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

@pizzadude
Copy link

pizzadude commented Oct 9, 2021

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

@mcatanzaro
Copy link
Contributor

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
Copy link
Collaborator

smcv commented Oct 9, 2021

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
Copy link
Contributor

mcatanzaro commented Oct 9, 2021

"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
Copy link
Collaborator

smcv commented Oct 9, 2021

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
Copy link
Collaborator

smcv commented Oct 9, 2021

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
Copy link

vchernin commented Oct 9, 2021

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
Copy link

Erick555 commented Oct 9, 2021

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
Copy link
Collaborator

smcv commented Oct 9, 2021

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
Copy link

Erick555 commented Oct 9, 2021

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
Copy link
Contributor

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

@Erick555
Copy link

Erick555 commented Oct 9, 2021

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

@mcatanzaro
Copy link
Contributor

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
Copy link

Erick555 commented Oct 9, 2021

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
Copy link

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

@smcv smcv closed this as completed in #362 Nov 10, 2021
smcv pushed a commit that referenced this issue Nov 10, 2021
These are not redundant with the GNOME version of these portals. They
are required for GTK apps running outside GNOME. It's a little sad that
we have portals in two different places, but I think that's just how it
needs to be.

Fixes #355
korewaChino pushed a commit to Ultramarine-Linux/comps-new that referenced this issue Jun 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants