Consider using GtkFileChooserNative instead of GtkFileChooserDialog

[dylanmccall]

At the moment, Avalonia's Gtk UI uses GtkFileChooserDialog. This means Avalonia applications running in a sandbox (such as Flatpak or Snap apps) will not be able to open files on the host unless they have been given access ahead of time. We can solve this by using GtkFileChooserNative, which has the ability to open a privileged file chooser that grants fine-grained access for a sandboxed application.

Glancing at the relevant code, I don't believe any GtkFileChooserDialog-specific API is being used, so it could be reasonably straightforward to change this code to use GtkFileChooserNative.

[kekekeks]

We are manipulating the window created by GtkFileChooserDialog to manually set the transient parent to Avalonia window. Unfortunately the dialog only accepts a _Gtk_Window as a parent and we can only get a _Gdk_Window for our XID using gdk_x11_window_foreign_new_for_display. So we extract a GdkWindow from the dialog and call gdk_window_set_transient_for.
I believe that won't be possible with GtkFileChooserNative since we don't have any control over it.

[kekekeks]

I think we should just use xdg-desktop-portal DBus APIs when it's available, that would solve both sandboxing issues and would allow us to use Qt-based dialog when running in KDE environment.

[dylanmccall]

Aha, I see that now. Yeah, that's always awkward with these things. That would be perfect, indeed!