Arch Linux

silikone

Member

Registered: 2024-05-25

Posts: 7

On GTK's retirement of GSettings

Arch Linux recently made the controversial decision (once again) to add XDG Desktop Portal as a core dependency of GTK4 in response to GSettings being dropped upstream.
As I understand it, this was a well established way to configure GTK to one's liking on minimal window managers where no portal interface for global settings may have been present as they would be on big desktop environments. Has the community been able to cope with the change so far? I haven't been able to find any recent complaints online after the latest commit, but the wiki page for GTK hasn't even been updated for a while and still appears to describe the use of GSettings as valid.

Personally, I am not too fond of this change from upstream. It reportedly caused Chromium to crash for a fellow Arch user, indicating that this is not merely a minor "compatible" update as the versioning number would suggest, but I guess that's to be expected of GTK.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,182

Re: On GTK's retirement of GSettings

What's the problem with having and having launched a portal provider? Many programs are switching to that even without GTK wanting to enforce it, because it's somewhat of a sensible way to have platform agnostic integration with platform specific functionality.

lawmurray

Member

From: Bangkok

Registered: 2025-02-10

Posts: 6

Website

Re: On GTK's retirement of GSettings

...GSettings being dropped upstream.

Do you have a link with further information? News to me is all.

seth

Member

From: Won't reply 2 private help req

Registered: 2012-09-03

Posts: 75,540

Re: On GTK's retirement of GSettings

@lawmurray, see https://gitlab.archlinux.org/archlinux/ … ote_450470

The portal stack is "somewhat" poorly designed…, but the thread seems to boil down to

Personally, I am not too fond [of this change from upstream…, but I guess that's to be expected] of GTK.

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 617

Re: On GTK's retirement of GSettings

What's the problem with having and having launched a portal provider?

Personally for me one of the reasons why I wouldn't want to have portal provider launched is that portal service is too loud and spams to journal. Without portal, if a client tries to access absent service, error handling is up to client: an error may be ignored or logged with specific priority. Portal unconditionally yells in such case, and developers won't change this (Example).

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,182

Re: On GTK's retirement of GSettings

While that stance is unfortunate, does https://wiki.archlinux.org/title/System … ing_levels in a drop-in not help here?

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 617

Re: On GTK's retirement of GSettings

While that stance is unfortunate, does https://wiki.archlinux.org/title/System … ing_levels in a drop-in not help here?

This will hide all warnings including potentially important ones. Increase log level every time something goes wrong and investigation required? Also despite messages disappear from journal, they are filtered on systemd side, so every attempt to log a message wakes up processes and triggers a chain of IPC.   
In general, making workarounds for a service which doesn't solve any real issue feels wrong for me. Just a multiplication of entities.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,182

Re: On GTK's retirement of GSettings

Yes, but seeing as the upstream we are talking about is the upstream we are talking about, you will eventually land either there (and if you are at the system config stage that things like these actively bother you you're more likely to make the inference and being able to relevantly reenable the log on a corresponding suspicion) or creating and maintaining a fork and/or shims that work like you want it to. Though I do find it somewhat sad that the original dev was fine with keeping it open to enable a one time log instead of a each time a connection happens log (which would probably alleviate this particular gripe) and it then getting closed again because people can't be bothered to provide constructive input and instead opting to harp on the same old point that got made already...

IMO from a conceptual standpoint to have a common layer that common functionality can be queried in a platform agnostic way the xdg-desktop-portals do their job reasonably well.

Last edited by V1del (2026-05-18 12:01:55)

silikone

Member

Registered: 2024-05-25

Posts: 7

Re: On GTK's retirement of GSettings

Log spam aside, the portal also brings in a slew of dependencies, such as Pipewire. I'm sure there are a few souls out there with a martyr complex that run a 100% ALSA setup. The silver lining for them is that XSettings is still available on their dwm-running IBM Thinkpads.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,182

Re: On GTK's retirement of GSettings

pipewire in a portal context is for screensharing, you can disable the audio portion and things in that regard will work fine. (yes I know your post is tongue-in-cheek but if someone happens to really ask themselves this question)

... and if you're against that application of it you're implicitly fine with every application being able to screengrab your entire screen at all times (since stuff like this is ultimately one of the motivators behind this setup)

stronnag

Member

Registered: 2011-01-25

Posts: 76

Re: On GTK's retirement of GSettings

Doesn't look like a retiring API to me https://docs.gtk.org/gio/class.Settings.html

silikone

Member

Registered: 2024-05-25

Posts: 7

Re: On GTK's retirement of GSettings

That's GIO, which is separate from GTK. GSettings is still used by frontends (and the entire GNOME ecosystem) to store their config. What's being retired is the GDK Wayland backend's GSettings fallback.
Portals can also make use of GSettings, which may or may not map to the prior GSettings used by GTK. Cinnamon/Mint, for instance, uses their own "XApp" GSettings for the desktop portal.

seth

Member

From: Won't reply 2 private help req

Registered: 2012-09-03

Posts: 75,540

Re: On GTK's retirement of GSettings

can be queried in a platform agnostic way the xdg-desktop-portals do their job reasonably well

1. reading files through a serial bus is a flat out dumb thing, popular with systemd and gnome only - portal kinda does this because it's meant for the flatschpak not-a-sandbox to isolate host files.
2. the various implementations collide what's addressed by hiding (some) services conditional to the DE
3. the varying implementations provide disjunct feature coverage but there's to my knowledge no query nor inherent failsafe plan, so if app developers forget to implement that, things are just broken
4. it's a single point of failure that can disfunct several applications and restarting those will not achieve anything, there's also no watchdog feature and the critical gtk implementation is written by gnome devs…

The overall approach makes somewhat sense with a security/data protection mind, but in general is just bloat.
getenv() works just fine and if one seeks dynamic adaptations (for settings) and can actually agree on some dbus API, one surely can also agree on some fucking ~/.local/share/palette for colors etc.
Also I seem to recall that Qt had no particular problems utilizing the UX disaster gnome calls a file picker, provided you run the Qt client in that environment.

xdg-desktop-portals was intended for, is geared towards flatschpak and is pushed for exactly that reason alone. cmv.

/rant

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

silikone

Member

Registered: 2024-05-25

Posts: 7

Re: On GTK's retirement of GSettings

I wholeheartedly agree. It's not like D-Bus is a novel paradigm on Linux that we haven't already had a chance to integrate. We've settled for direct file system access multiple times until we (read: GNOME) decided that sandboxing is the rule rather than the exception.
Don't get me wrong, it's a virtuous endeavor to make sandboxing as transparent as possible, but gimping the entire desktop suite to satisfy that is inane.