Subject: Re: [bug#73520] [PATCH 0/2] Potential fix for the latest xdg-desktop-portal

From: Maxim Cournoyer <[email-masked]>
Date: Sun, 19 Jan 2025 21:27:23 +0900

Hi Rodion (and John!),

John Kehayias <[email-masked]> writes:

[...]

>> Hello!
>>
>> The problem with the xdg-desktop-portal is due to the configuration
>> changes introduced in this commit [1].
>
> By problem, do you mean (or also mean) what was reported as breaking in
> Gnome in <https://issues.guix.gnu.org/73403#2>? Have been able to test
> that this patch fixes that issue?

I'm not Rodion, but I assume that's what they meant!

>> Now it relies on using the configuration file to decide which
>> xdg-desktop-portal implementation to use. However, as Guix uses
>> XDG_DESKTOP_PORTAL_DIR to specify the portal (not the
>> xdg-portal-configuration) directory, the newest xdg-desktop-portal
>> skip configuration search at all [2].
>> If we patch the process of configuration search a little bit - just
>> to continue searching in case the XDG_DESKTOP_PORTAL_DIR is
>> specified, but doesn't contain any {*}-portals.conf files (our
>> case), we will have the right configuration files (at least for KDE
>> I have tested this changes on) to be read by xdg-desktop-portal
>> according to priorities (XDG_DATA_DIRS in our case) [3] (so they
>> could be even overridden in users' home directory).
>>
>
> Thanks for the details! I haven't had a chance to look at this carefully
> yet. Has this been reported upstream? Is this something that should be
> fixed there or is this too particular to a Guix system?

Is it expected that XDG_DESKTOP_PORTAL_DIR as set by Guix can lack a
any *-portals.conf files?  That seems odd.

If there's a good reason for that to happen (a valid use case), then an
issue should be opened upstream to start some conversation about this
change of behavior and the best way it should be addressed.

-- 
Thanks,
Maxim