[mahkoh]

>Back when I was writing xdg-desktop-portal-hyprland, I had to use a few dbus protocols (xdg portals run on dbus) to implement some of the communication. If we go to the portal documentation, we can find the protocols.

>[...]

>None of the apps, I repeat, fucking none followed the spec. [...]

>Fun fact: THIS IS STILL THE CASE! The spec advertises a "restore_token" string prop on SelectSources and Start, where no app does this and uses "restore_data" in "options".

Wrong. xdg-desktop-portal has a client API and a compositor API. In the client API the property is called restore_token [1]. In the compositor API the property is called restore_data [2]. Clients do not talk directly to the compositor, they talk to the xdg-desktop-portal application which then talks to the compositor. It is not surprising the the properties would not be called the same.

In the documentation the APIs for app developers and desktop developers are clearly separated on the left hand side [3]. Not only does this have nothing to do with DBus (it would apply to every API where a middleware is used to translate messages), it also shows that the author did not do his due dilligence.

[1]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[2]: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...

[3]: https://flatpak.github.io/xdg-desktop-portal/docs/

[Sprocklem]

> It is not surprising the the properties would not be called the same.

It is a bit surprising that xdg-desktop-portal has two very similar APIs that differ in non-obvious and seemingly-arbitrary ways. I was also a bit confused about how the two APIs correspond (or don’t) when I first read their documentation.