Flatpak/Snap specific behavior should be documented

[xi]

Operating System

any

XDG Desktop Portal version

1.18

XDG Desktop Portal version (Other)

No response

Desktop Environment

GNOME

Desktop Environment (Other)

No response

Expected Behavior

Developers who use xdg-desptop-portal should be able know how it will behave. Specifically, the documentation should

• note that there is code specific to Snap / Flatpak
• explain the behavior that is specific to Flatpak
• explain the behavior that is specific to Snap

It would be even better if none of this was necessary. In the long run, all mechanisms that are necessary for sandboxing should be standardized. Listing the missing bits and pieces in the documentation could be a first step towards standardisation.

Current Behavior

The website gives the impression that xdg-desktop-portal behaves the same for any desktop containment framework. Only when I read #680 (comment) did I learn that it contains code that is specific to Flatpak / Snap. When i looked at the code, I realized that this is not limited to the File Chooser portal but also affects many other places. I was not yet able to get a clear picture of how exactly xdg-desktop-portal is entangled with Flatpak / Snap.

Steps to Reproduce

Read the documentation, then try to use the File Chooser portal with a desktop containment framework other than Flatpak or Snap.

Anything else we should know?

Releated to #737

[swick]

This isn't really actionable. Documenting this seems like documenting an implementation detail.

The code that's specific to the kind of app has been refactored and is entirely self-contained in xdp-app-info-$KIND.c. I also have plans to add a new kind that is generic and will work with any app kind that sets a bit of metadata on the cgroup and implements a dbus interface.

[xi]

I also have plans to add a new kind that is generic and will work with any app kind that sets a bit of metadata on the cgroup and implements a dbus interface.

That is exactly the kind of solution that I was hoping for (as long as it is properly documented of course).

[MaeIsBad]

I also have plans to add a new kind that is generic and will work with any app kind that sets a bit of metadata on the cgroup and implements a dbus interface.

Is there a tracking issue for this I can subscribe to?