Wrong portal is used for org.freedesktop.portal.Settings

[WhyNotHugo]

I've a portal of my own handling Settings:

$ cat /usr/share/xdg-desktop-portal/portals/darkman.portal
[portal]
DBusName=org.freedesktop.impl.portal.desktop.darkman
Interfaces=org.freedesktop.impl.portal.Settings
UseIn=sway

And have set up the GTK portal to handle only filechooser and a few other interfaces (but not settings):

$ cat /usr/share/xdg-desktop-portal/portals/gtkonly.portal
[portal]
DBusName=org.freedesktop.impl.portal.desktop.gtk
Interfaces=org.freedesktop.impl.portal.FileChooser;org.freedesktop.impl.portal.AppChooser;org.freedesktop.impl.portal.Print;org.freedesktop.impl.portal.Notification;org.freedesktop.impl.portal.Inhibit;org.freedesktop.impl.portal.Access;org.freedesktop.impl.portal.Account;org.freedesktop.impl.portal.Email;org.freedesktop.impl.portal.RemoteDesktop;org.freedesktop.impl.portal.Lockdown;org.freedesktop.impl.portal.Background;org.freedesktop.impl.portal.Wallpaper;
UseIn=sway

The correct desktop is also set:

$ systemctl --user show-environment | grep XDG_CU
XDG_CURRENT_DESKTOP=sway

But when querying the the desktop portal, it seems to be fetching the value from the gtk portal.

$ dbus-send  --print-reply=literal --dest=org.freedesktop.impl.portal.desktop.darkman /org/freedesktop/portal/desktop org.freedesktop.impl.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme
   uint32 1
$ dbus-send  --print-reply=literal --dest=org.freedesktop.impl.portal.desktop.gtk /org/freedesktop/portal/desktop org.freedesktop.impl.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme
   variant       uint32 0
$ dbus-send  --print-reply=literal --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme
   variant       variant          uint32 0

It seems that xdg-desktop-portal is using the gtk portal, even though my setup explicitly sets another one as preferred. At least the value matches that.

As extra confirmation, if I stop xdg-desktop-portal-gtk.service, and then run $ dbus-send --print-reply=literal --dest=org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read string:org.freedesktop.appearance string:color-scheme, xdg-desktop-portal-gtk.service is auto-started again.

[WhyNotHugo]

Oh, some previous mentions of this issue here: elementary/settings-daemon#38 (review)

[WhyNotHugo]

As far as I understand, portals are iterated, and whenever one returns a value, that value is considered final.

As a potential solution: perhaps iterating portals with a matching UseIn= first would be best (and only fall back to other portals if none of these reply)?

[alice-mkh]

One big problem here that I discovered later - is that regardless of which portal will actually be used, all of them will notify on changes, passing their own values as the parameter.

[Marukesu]

As a potential solution: perhaps iterating portals with a matching UseIn= first would be best (and only fall back to other portals if none of these reply)?

That was done in #670.

One big problem here that I discovered later - is that regardless of which portal will actually be used, all of them will notify on changes, passing their own values as the parameter.

This is only a problem if there's some process that change the value that the backend use right? for example, in elementary, even with the GTK backend build from master, it will never emit the SettingChanged for color-scheme because there isn't any process that try to change it.

[alice-mkh]

Well, if you use gsettings cli to change the GNOME gsettings key, it will emit a change with the value from gsettings and apps will switch. Then you'll have to toggle the elementary pref back and forth to reset it.

The way I found it was via the fact https://gitlab.gnome.org/exalm/color-scheme-simulator was sorted after the gtk portal - and so you get the gtk value on startup but simulator values on changes...

[WhyNotHugo]

My portal is simply named darkman, and is listed before the GTK one -- so if they're picked based on alphabetical order, it should be used.

It's also the only one with a matching UseIn=, so fix in #670 doesn't seem to be picking in this particular case.

[WhyNotHugo]

I think part of the issue here is that the GTK portal returns 0 for this key -- it should not return any value, right?

On gnome, the gnome portal will handle this setting. The gtk portal is expected to run on other non-gnome platforms, and should not set any preference of its own. Or am I missing something here?

I'm mostly asking because I wonder if it also calls the SettingChanged, which would always be problematic.

[Marukesu]

My portal is simply named darkman, and is listed before the GTK one -- so if they're picked based on alphabetical order, it should be used.

It's also the only one with a matching UseIn=, so fix in #670 doesn't seem to be picking in this particular case.

You can run /usr/libexec/xdg-desktop-portal -vr to see the order used in the settings portal.

I think part of the issue here is that the GTK portal returns 0 for this key -- it should not return any value, right?

On gnome, the gnome portal will handle this setting. The gtk portal is expected to run on other non-gnome platforms, and should not set any preference of its own. Or am I missing something here?

Right now, it's use the org.gnome.desktop.interface.color-scheme gsetting key, returning 0 (No Preference) when it not exist. I believe it should throw an error instead, since returning any value means that the key is provided when in reallity it isn't.

However, maybe the issue for your backend is that it return an uint instead of an variant holding an uint. the portal should be ignoring it and asking the next backend.

I'm mostly asking because I wonder if it also calls the SettingChanged, which would always be problematic.

the portal don't set the key by itself but only notifies when it change, so, unless the user or program/script changed it, the portal won't emit the SettingChanged at all.

[WhyNotHugo]

XDP: Read org.freedesktop.appearance color-scheme
XDP: Failed to Read() from Settings implementation: Method “Read” returned type “(u)”, but expected “(v)”

That was the issue, my code was returning uint instead of Variant(uint). Fixing that solved the issue immediately.

I'll try to add some details from these responses to the docs for the settings portal. It should help both client and server implementations.

the portal don't set the key by itself but only notifies when it change, so, unless the user or program/script changed it, the portal won't emit the SettingChanged at all.

Oh, that's nice to know.

[WhyNotHugo]

Oh, thanks for the guidance here, this is fixed.