-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use XDG Desktop Portal on Linux #36
Comments
GTK supports XDG desktop portal by default, I use it to publish one of my apps as Flatpack. 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. |
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. |
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. |
Alternatively this could use the zbus crate which is a pure Rust library for dbus. |
Yep, that was my plan already 😉 |
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. |
Oh, that's a great find! I totally forgot about its existence. |
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:
|
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. |
The message dialog code is within the |
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 |
I think I'm in over my head here... ashpd only has an async API, but I can't use |
Not sure if I follow, why do we need async trait fn here? Can't we just return 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? |
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;
})
}
} |
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes PolyMeilex#36
* use XDG Desktop Portal on Linux & BSDs This new backend does not support MessageDialog nor AsyncMessageDialog because there is no corresponding API in the XDG Desktop Portal. The GTK backend is still available with the new `gtk3` Cargo feature. Fixes #36 * replace smol with pollster pollster is smaller than smol * rename unwrap_or_warn to ok_or_warn * reuse async functions to implement sync functions * replace Option::ok with ok_or_warn * impl From<FileHandle> for PathBuf to reduce code duplication * cargo fmt * factor out file_chooser_proxy function * add link to ashpd issue for RawWindowHandle bilelmoussaoui/ashpd#40 * make gtk3 a default feature
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.
The text was updated successfully, but these errors were encountered: