use XDG Desktop Portal on Linux

[Be-ing]

Using XDG Desktop Portal would solve two problems. It would automatically use the desktop environment's dialog, plus it would let rfd work in Flatpak sandboxes. IIUC this could be done with the dbus crate. If the portal isn't available, the old GTK implementation could be used as a fallback, but I think that should be turned into a Cargo feature to remove this crate's dependency on GTK.

[PolyMeilex]

GTK supports XDG desktop portal by default, I use it to publish one of my apps as Flatpack.
But yeah, we could implement our own dbus version, probably using zbus crate, in case someone dos not want to depend on GTK.

EDIT: It would also remove a lot of if'y unsafe code that GTK forces us to use. DBus version would basically be 100% safe Rust.

[Be-ing]

in case someone dos not want to depend on GTK

I think this would be quite common. I intend on distributing my application, which otherwise has no dependency on GTK, as a Flatpak. It would be silly to require the GNOME Flatpak runtime just for a file picker dialog -- even if the Flatpak gets run on KDE and GTK is only used to indirectly open KDE's file picker through the XDG Desktop Portal.

[Be-ing]

Hmm, apparently the Freedesktop Flatpak runtime has GTK3, so I suppose this wouldn't make a difference with regard to packaging Rust applications in Flatpaks. However it would still be good to remove the dependency on GTK.

[Be-ing]

Alternatively this could use the zbus crate which is a pure Rust library for dbus.

[PolyMeilex]

But yeah, we could implement our own dbus version, probably using zbus crate, in case someone dos not want to depend on GTK.

Yep, that was my plan already 😉

[Be-ing]

I just found out about the ashpd crate which provides a nice Rust API for the XDG Desktop Portal using zbus. I'll work on using that crate to implement this.

[PolyMeilex]

Oh, that's a great find! I totally forgot about its existence.

[Be-ing]

I don't know what to do to implement the generic message dialog stuff with the XDG Desktop Portal... nor am I interested in that functionality because I can use the GUI library I'm already using (SixtyFPS) to do that. I can think of a few ways to handle this, in order of my preferences:

1. Move the message dialog code to a separate crate.
2. Put the message dialog code behind a Cargo feature.
3. Abuse the notifications of the XDG Desktop Portal for this... not sure if that could really work.
4. Use XDG Desktop Portal for the file dialog and GTK for the message dialog. That would kinda defeat the purpose for me because I want to remove the dependency on GTK from my application.

[PolyMeilex]

Yeah, it makes sense, there is no point in placing msg dialogs behind desktop portal.

RFD already has differences depending on the platform, all of those are noted in docs, and for example sync dialogs are behind conditional compilation because wasm does not support them.

My idea would be to simply not compile message module when xdg desktop portal feature is enabled, and document it property to let the user know what are the downsides of using this backend of rfd.

[Be-ing]

message module

The message dialog code is within the dialog module currently. Shall I start with a PR to move it to its own module? Or a submodule of dialog?

[PolyMeilex]

Yeah sure, we can split it into two modules, backends already follow this convention, so it makes sense to do the same for dialog module

[Be-ing]

I think I'm in over my head here... ashpd only has an async API, but I can't use await to implement AsyncFilePickerDialogImpl because async fn is still not supported for traits. I suppose this library could run its own async executor... which seems like an ugly hack that might not compose well with whatever executor the application using this library is running. I don't understand how async libraries can be composed with this limitation.

[PolyMeilex]

Not sure if I follow, why do we need async trait fn here? Can't we just return impl Future<> like we do for every other backend?
I'll have a closer look at ashpd tomorrow, but I'm pretty sure it's not a problem async fn is just a syntax sugar around Futures.

Something like this:

 pub fn pick_file(self) -> impl Future<Output = Option<File>> {
        async move {
                whatever().await
        }
 }

Or like this:

 pub fn pick_file(self) -> impl Future<Output = Option<File>> {
       inner()
 }
 
 async fn inner() -> Option<File> {
         whatever().await
 }

Should be enough.

Or am I missing an important piece of the puzzle somewhere?

[Be-ing]

Ah, thanks for the tip. This is getting somewhere now:

impl AsyncFilePickerDialogImpl for FileDialog {
    fn pick_file_async(self) -> DialogFutureType<Option<FileHandle>> {
        Box::pin(async {
            async_function_call.await;
        })
    }
}