settings: Remove org.freedesktop.appearance and color-scheme

[ItsJamie9494]

Since ReadAll() in xdg-desktop-portal doesn’t handle conflicting namespaces properly, and xdg-gtk has no reason to use this key (xdg-gnome handles it), it should be safe to remove org.freedesktop.appearance as well as the color-scheme key

[alice-mkh]

Another reason is that having a generic portal point to GNOME preference is not very useful - the idea is that each desktop has its own settings, not that everyone uses the GNOME pref, so this just caused false positives on https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.StyleManager.system-supports-color-schemes.html

[JoshStrobl]

This should not be merged. The following desktop environments currently are able to and actively use xdg-desktop-portal-gtk

• Budgie Desktop 10 series
• MATE
• XFCE

In the case of Budgie Desktop, we plan on developing a portal for Budgie 11 and currently apply color-scheme in git builds when toggling dark mode. In the case of MATE, it has been requested that they implement their own portal in this feature request. Discussions are not active in the respective XFCE FR seeing as the GTK one works and as a result not considered a priority.

Regardless, removal of this functionality would leave users of three desktop environments hanging dry. In the case of Budgie Desktop, we recommend the GTK portal over GNOME, and the GTK portal is what ships with Fedora Budgie Spin (and as of Fedora 39, Fedora Onyx).

[smcv]

This should not be merged

I would be inclined to agree.

Now that xdg-desktop-portal 1.17.x has the portals.conf mechanism, any desktop that wants to use or not use the x-d-p-gtk implementation for this interface can configure its ${desktop}-portals.conf accordingly. For example, if a desktop environment wants to use x-d-p-mydesktop or x-d-p-gtk for most things, but exclude x-d-p-gtk from providing Settings, it can do that:

[preferred]
default=mydesktop;gtk;
org.freedesktop.impl.portal.Settings=mydesktop;

[alice-mkh]

portals.conf somewhat obsoletes it, indeed. That said, not sure how useful it is to point to a GNOME preference (which has no stability guarantees around it of any kind, it's an implementation detail) for other desktops.

[JoshStrobl]

I won't get into the configuration and ABI stability guarantees of GNOME and will limit the comments to what I already expressed: This is used by other desktop environments. Whether GNOME thinks their keys should be used, or the GTK portal should be used, in other desktop environments is not relevant to the fact that they are being used and will continue to be used in the foreseeable future.

I would have objections to this even if it was limited to just the removal of the GNOME key as expressed above, but removal of the generic one as well is a strong pendulum swing in the wrong direction. The GTK portal should support both and re-evaluated in the future when the respective GTK-based desktop environments have implemented their own portals.

[JoshStrobl]

In terms of the portal configuration, this is implemented in Budgie Desktop with https://github.com/BuddiesOfBudgie/budgie-desktop/commit/98f20ad11678dd3732d3699e7ca564434fb61356

[alice-mkh]

That's true, the main mistake here was adding it to -gtk in the first place. This should have never been done, and removing things is a lot harder than adding them. At least this isn't being repeated for newer settings.

[JoshStrobl]

Yep, that I agree with. I'm all for removing the GNOME key (at the very least) when we know it isn't going to impact users of a bunch of other desktop environments. I think we'd all eventually like to see most of the GTK one not be considered necessary down the road when hopefully the portal implementation situation is in a healthier state. Unfortunately not everyone can move at the breakneck speed of GNOME :)

[TingPing]

I also don't think this should be merged. So I think its OK to close this.