portal-impl: Hard-code x-d-p-gtk as a last-resort fallback

[smcv]

x-d-p-gtk has historically been used as the portal implementation of last resort, and in particular, users of assemble-it-yourself desktop environments or otherwise-unsupported desktop environments have tended to rely on it for basic functionality, particularly now that its GNOME-specific parts have been removed.

We don't want to install a /usr/share/x-d-p/portals.conf that makes it the fallback (as proposed in xdg-desktop-portal#1192) because that would be higher-precedence than the fallback to the legacy UseIn mechanism. For example, x-d-p-wlr has UseIn=...;Wayfire;... which means that it will be used to provide screenshots and screencasts under Wayfire (even without fixing WayfireWM/wayfire#1995), but installing a /usr/share/x-d-p/portals.conf with only default=gtk would defeat that.

Instead, search for x-d-p-gtk as a lower precedence than the legacy UseIn mechanism. This means that (for example) users of Wayfire will get screenshots from x-d-p-wlr and file choosers from x-d-p-gtk unless configured otherwise, while users of environments with no more appropriate portal configuration at all (for example fvwm) will get x-d-p-gtk.

This change was previously a Debian-specific patch with a slightly different warning.

Resolves: #1102

---

Alternative to #1192 and the unfinished #1103.

[smcv]

v2:

• add a comment as @ebassi requested
• rescue a commit from Add fallback configuration for what to do if no portal is found via UseIn #1103 so we only emit the warning about using portals.conf(5) once, even though there are now two places that could be the first to emit it

[liskin]

This only handles interfaces that use find_portal_implementation, but org.freedesktop.impl.portal.Settings is a special case that uses find_all_portal_implementations and that function won't add xdg-desktop-portal-gtk to the list unless it's explicitly requested in a portals.conf file. So in the absence of portals.conf, there will be no impl for org.freedesktop.impl.portal.Settings despite xdg-desktop-portal-gtk being a perfectly valid fallback impl for it.

The consequence is that users of these lightweight desktop environments aren't for example able to override org.freedesktop.appearance.color-scheme for libadwaita applications, as libadwaita uses xdg-desktop-portal to retrieve the preference.

Any chance the fallback can be extended to org.freedesktop.impl.portal.Settings?

[smcv]

This only handles interfaces that use find_portal_implementation, but org.freedesktop.impl.portal.Settings is a special case that uses find_all_portal_implementations and that function won't add xdg-desktop-portal-gtk to the list unless it's explicitly requested in a portals.conf file. So in the absence of portals.conf, there will be no impl for org.freedesktop.impl.portal.Settings despite xdg-desktop-portal-gtk being a perfectly valid fallback impl for it.

Please open a separate issue rather than replying to a closed pull request.

Any chance the fallback can be extended to org.freedesktop.impl.portal.Settings?

If there is a reasonable way to describe the desired fallback, and it's implementable, then I think that would make sense. Perhaps you could open a pull request?

The consequence is that users of these lightweight desktop environments aren't for example able to override org.freedesktop.appearance.color-scheme for libadwaita applications

If either the desktop environment or an individual user wants to provide a portals.conf that expresses a preference, that is certainly something that they can do. For example, dwm as packaged in Debian

[smcv]

If there is a reasonable way to describe the desired fallback

I think there are two things that could be considered reasonable fallbacks for find_all_portal_implementations(): "the fallback is a list containing only -gtk", or "the fallback is a list of every installed portal backend that implements Settings". The latter is what happened in 1.16.x and earlier, and is maybe a better answer for Settings than just -gtk (but if you're the one implementing this, it's up to you to choose something reasonable).

Please bear in mind, though, that these last-resort fallbacks are a last resort, and if you want full control, there are better ways to achieve that control (like having your minimal desktop environment announce a name for itself and select one or more suitable Settings backends, similar to what was done in the Debian packaging for dwm).

[liskin]

Perhaps you could open a pull request?

I'll see what I can do (tomorrow-ish) 🙂

I think there are two things that could be considered reasonable fallbacks for find_all_portal_implementations(): "the fallback is a list containing only -gtk", or "the fallback is a list of every installed portal backend that implements Settings". The latter is what happened in 1.16.x and earlier, and is maybe a better answer for Settings than just -gtk (but if you're the one implementing this, it's up to you to choose something reasonable).

Oh, this is helpful. Gives me some thoughts to start with. I've also discovered a couple other related issues and pull requests discussing this, and I think the sentiment there was that "every installed portal backend that implements Settings" isn't desirable because x-d-p-gnome misbehaves when not running in an actual GNOME session. So I'm leaning towards making find_all_portal_implementations behave as close to find_portal_implementation as possible, as that seems the least suprising. That would mean "the fallback is a list containing only -gtk", and perhaps even to look for the UseIn stuff before the last resort fallback to -gtk.

Please bear in mind, though, that these last-resort fallbacks are a last resort, and if you want full control, there are better ways to achieve that control (like having your minimal desktop environment announce a name for itself and select one or more suitable Settings backends, similar to what was done in the Debian packaging for dwm).

As a user, I understand that and I obviously created a local portals.conf as soon as I discovered what the issue is. Still, I was very surprised to find that org.freedesktop.impl.portal.Settings doesn't have a fallback while everything else does. Surprises are bad.

As a maintainer of a lightweight window manager that happens to work (and be used) in multiple desktop environments, I'm not really in a position to ship a portals.conf, I can merely document that one is needed. But then, one is needed only because x-d-p doesn't consistently select a fallback impl for all interfaces. From this point of view, it seems better to fix this upstream rather than downstream—make x-d-p behave consistently, so users running a window manager outside of a desktop environment don't need to be surprised.

I mean, if the whole fallback mechanism wasn't there, I'd notice pretty quickly that I need a portals.conf. A half-functioning fallback, however, takes a while to diagnose… (I'm almost ashamed to admit how long it took me)
So if x-d-p upstream ended up accepting the fallback mechanism (I understand there was quite a discussion about this back then), there shouldn't really be opposition to making it work consistently—I hope. 🙂

Anyway, PR tomorrow-ish.

[liskin]

Anyway, PR tomorrow-ish.

#1358

(apologies for adding another comment to a closed PR, this is the last one now that we have a PR 😃)