bilelmoussaoui/ashpd#40

It is common to have three buttons in a dialog:

When a file is dragged from an open rfd dialog and dropped in a winit window the program crashes with the error:

(exit code: 0xc0000374, STATUS_HEAP_CORRUPTION)

https://docs.rs/crate/rfd/0.8.0/builds/511355

# build log
[INFO] running `Command { std: "docker" "create" "-v" "/home/cratesfyi/workspace/builds/rfd-0.8.0/target:/opt/rustwide/target:rw,Z" "-v" "/home/cratesfyi/workspace/builds/rfd-0.8.0/source:/opt/rustwide/workdir:ro,Z" "-v" "/home/cratesfyi/workspace/cargo-home:/opt/rustwide/cargo-home:ro,Z" "-v" "/home/cratesfyi/workspace/rustup-home:/opt/rustwide/rustup-home:ro,Z" "-e" "SOURCE_DIR=/opt/rustwide/workdir" "-e" "CARGO_TARGET_DIR=/opt/rustwide/target" "-e" "DOCS_RS=1" "-e" "CARGO_HOME=/opt/rustwide/cargo-home" "-e" "RUSTUP_HOME=/opt/rustwide/rustup-home" "-w" "/opt/rustwide/workdir" "-m" "3221225472" "--cpus" "3" "--user" "1001:1001" "--network" "none" "ghcr.io/rust-lang/crates-build-env/linux@sha256:0cd99ca24d8e8c98e67c542213511d985b8778b5bdcbb160e038429496686047" "/opt/rustwide/cargo-home/bin/cargo" "+nightly" "rustdoc" "--lib" "-Zrustdoc-map" "--all-features" "-Z" "unstable-options" "--config" "build.rustdocflags=[\"-Z\", \"unstable-options\", \"--emit=invocation-specific\", \"--resource-suffix\", \"-20220216-1.60.0-nightly-75d9a0ae2\", \"--static-root-path\", \"/\", \"--cap-lints\", \"warn\", \"--disable-per-crate-search\"]" "-Zunstable-options" "--config=doc.extern-map.registries.crates-io=\"https://docs.rs/{pkg_name}/{version}/x86_64-unknown-linux-gnu\"" "-j3" "--target" "x86_64-unknown-linux-gnu", kill_on_drop: false }`
[INFO] [stderr] WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
[INFO] [stdout] 74d3a2d57ce73a0c562bffbe581f5b9c63f7c80795df7f9220d87ca89b7b21c1
[INFO] running `Command { std: "docker" "start" "-a" "74d3a2d57ce73a0c562bffbe581f5b9c63f7c80795df7f9220d87ca89b7b21c1", kill_on_drop: false }`
[INFO] [stderr]    Compiling rfd v0.8.0 (/opt/rustwide/workdir)
[INFO] [stderr]    Compiling futures-core v0.3.21
[INFO] [stderr]    Compiling serde_derive v1.0.136
[INFO] [stderr]    Compiling futures-task v0.3.21
[INFO] [stderr]    Compiling serde v1.0.136
[INFO] [stderr] error: You can't enable both GTK3 & XDG Portal features at once
[INFO] [stderr]  --> build.rs:9:5
[INFO] [stderr]   |
[INFO] [stderr] 9 |     compile_error!("You can't enable both GTK3 & XDG Portal features at once");
[INFO] [stderr]   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stderr] 
[INFO] [stderr]    Compiling futures-channel v0.3.21
[INFO] [stderr] error: could not compile `rfd` due to previous error
[INFO] [stderr] warning: build failed, waiting for other jobs to finish...
[INFO] [stderr] error: build failed

Maybe there is a way to tell the builder which features to enable?

I see that the Cargo.toml of this library contains license = "MIT", but there is no LICENSE file in the repository. Would it be possible to add this?

Hi, guys. How do I get the LNK command line parameters

Paths with a Win32 namespace look like this: \\?\C:\windows. See https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces for details. Paths of this form are returned by Path::canonicalize() and fs::canonicalize().

When these namespaced paths are used with FileDialog::set_directory(), the dialog opens in the current working directory or the user's documents instead of the requested directory (at least in 0.6.0. The dialog fails to open at all in 0.5.1!)

For instance, this patch:

diff --git a/examples/simple.rs b/examples/simple.rs
index fca64c2..8f7105c 100644
--- a/examples/simple.rs
+++ b/examples/simple.rs
@@ -1,11 +1,9 @@
 #[cfg(not(target_arch = "wasm32"))]
 fn main() {
-    let path = std::env::current_dir().unwrap();
-
     let res = rfd::FileDialog::new()
         .add_filter("text", &["txt", "rs"])
         .add_filter("rust", &["rs", "toml"])
-        .set_directory(&path)
+        .set_directory(r"\\?\C:\windows")
         .pick_files();

     println!("The user choose: {:#?}", res);

Should open the dialog in the C:\windows directory when running the simple example on Windows. Remove the \\?\ namespace prefix and it works as expected.

I'm using rfd in a larger project. In a thread separate from the main one, I'm showing a file dialog to either open or save a file when the user clicks a button. Sometimes the file dialog shows, and I can interact with it properly. But about half of the time, the dialogs don't open at all. Here's the link to the line that sometimes fails. I'll try to come up with a MWE later today or tomorrow.

I had previously tried using native-dialog, which had a similar behavior, except that instead of silently failing, it crashed with an ImplementationError("CoInitializeEx") error.

I haven't been able to test this on Linux, and this fails on MacOS due to the issue of me running this outside of the main thread in the first place.

This is follow-up for #32.

The Rust std library recently got better support for handling special Windows paths in rust-lang/rust#89174 (stabilized in 1.58.0).

While going through the PR, I noticed some other path prefixes that I was not aware of: https://github.com/rust-lang/rust/pull/89174/files#diff-1d1bc84d05775ebd4b147542747b8e57edf520a54935771ce1d85f383596aa64R169-R174

And digging even further, I have seen some sources claim that way Windows handles paths is incredibly complex: https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html (All I can really say is that the 36-year lineage of Windows did not do it any favors.)

On linux, the type FileHandle is Send and Sync. On wasm32 FileHandle is !Send and !Sync.

It makes a little bit harder to do multiplatform code because a code that worked on Linux may not compiled on Wasm32.

Would be nice to do a new patch release of the crate to publish the fix in #26

RFD uses gtk_file_chooser_set_filename on GTK (Linux), and it works great. It would be great if we could also set the current file name in the dialog, using gtk_file_chooser_set_current_name. I'm not sure what would be the API to use on Mac/Windows though.

Typical Rust user expects API use case like this for non blocking dialog:

std::thread::spawn(||{
  rfd::pick_file(None);
});

But this way is impossible for file dialogs, because macOS expects us to create dialogs on main thread.
So I guess we are forced to use async/await to mitigate this a little.

// Create dialog on main thread
let dialog = rfd::pick_file_async(None);
some::async::executor(async{
  // Wait for it somewhere else
  dialog.await;
});

But.... for non-blocking dialogs, UI toolkits usually need some sort of internal event loop.

• In GTK we can iterate events manually (for example in pull() fn) (there are some multi threading issues with this but it's quite usable)
• And in macOs (as far as I know) there is no way to iterate events manually, so we have to run a event loop every time dialog is created or expect that a user has one. This means that if user is using winit dialog will be fully async, but If user does not use it, rfd will have to run it's own event loop, which means that dialog will block even tho it's marked as async function, and that's super confusing for a user
• In wasm32 there is no problem with this, the situation is opposite there, only async dialogs are allowed
• win32 not investigated yet

I noticed an inconsistency between the synchronous and asynchronous APIs. The synchronous APIs use PathBuf, but the async APIs use FileHandle. Is this inconsistency intention, and if so, why?

Thanks for creating this library and the time invested in it! Are there plans to crate support for the android platform in the future?

Hi,

Really great library, love it!

I found a weird behavior that you can see on the screenshot:

Here, I pressed S and the file dialog is in fact open. I can confirm that because my touchbar gives me two choices:

• Cancel
• Save

How To Reproduce

• Open a terminal in fullscreen
• Reach the winit-example
• Run cargo run
• Press S

I tried to use AsyncFileDialog in an iced app on macOS, but when trying to use the dialog, the app crashes, printing:

fatal runtime error: Rust cannot catch foreign exceptions

This happens on 0.1.2 as well as master.

I'm trying to use the save_file API with a default directory and file_name but the GTK usage is wrong, it doesn't work when the file already exists. I've adapted the save example to test this:

#[cfg(not(target_arch = "wasm32"))]
fn main() {
    let path = std::env::current_dir().unwrap().join("examples");

    let res = rfd::FileDialog::new()
        .set_file_name("async.rs")
        .set_directory(&path)
        .save_file();

    println!("The user choose: {:#?}", res);
}

#[cfg(target_arch = "wasm32")]
fn main() {
    // On wasm only async dialogs are possible
}

If I remove the set_file_name call, at least it changes to the examples folder.

Same thing applies to the pick_file APIs. The following example doesn't work:

#[cfg(not(target_arch = "wasm32"))]
fn main() {
    let path = std::env::current_dir().unwrap().join("examples");

    let res = rfd::FileDialog::new()
        .add_filter("text", &["txt", "rs"])
        .add_filter("rust", &["rs", "toml"])
        .set_directory(&path)
        .set_file_name("async.rs")
        .pick_file();

    println!("The user choose: {:#?}", res);
}

#[cfg(target_arch = "wasm32")]
fn main() {
    // On wasm only async dialogs are possible
}

But it does work if I remove the set_directory call and use .set_file_name(&path.join("async.rs").display().to_string()) instead. Which makes sense if you read the GTK documentation for gtk_file_chooser_set_filename.

In short, I think I could get along with the current API if we could expose set_current_name (only available on Linux). Let me know what you think about this.

Thanks in advance! I love this crate.

The example doesn't compile in both native and WASM.

I'm using rfd 0.10

I don't know if this is a rfd or a winit bug, but if you drop a file onto a winit window on MacOS and try to show a dialog as a response, the AsyncMessageDialog does not work. Instead, the "Hi! It looks like you are running async dialog in unsuported environment, I will fallback to sync dialog for you." gets printed. I think this is because the app.key_window() at line 58 of modal_future.rs is actually null.
It is easy to reproduce this by making a small change to the winit example, see my branch: https://github.com/francesco-cattoglio/rfd/tree/dropped_file_bug
To reproduce, just start the example and drag any file from the MacOS Finder onto the window.

To quote #77:

TD_WARNING_ICON / TD_ERROR_ICON / TD_INFORMATION_ICON are missing so I use hard code to workaround.

This should be removed once microsoft/win32metadata#968 is fixed and released

Per the AppKit docs, allowedFileTypes is deprecated. We should use allowedContentTypes if available. I believe I can PR this this weekend.

This could be useful to create objects that can produce several messages.

struct MessageProducer {
level: MessageLevel
}

impl MessageProducer {
  fn message(&self) {
    AsyncMessageDialog::new().set_level(self.level).set_description("Hi").show(); // Can't move level out of self :( 
  }
}

Also, I love this crate ❤️ , I was so happy to find a cross-platform solution for dialogs that would not freeze on MacOS when using winit

More details here: mlua-rs/mlua#184

I'm trying to figure out a very strange interaction between rfd and mlua that breaks the latter in very subtle ways. This issue can only be reproduced when using the gtk-3 backend on Linux. I tried switching to xdg-portal and that one seems unaffected.

I'm reporting this here in case you have an idea of something in the gtk-3 backend that might be introducing some subtle UB? I honestly don't know where the issue lies in, so I'm reporting in both places 😄

Blocked by:

• microsoft/windows-rs#432
• microsoft/windows-rs#638

It would be fantastic if the button texts can be customized:

pub enum MessageButtons {
    Ok,
    OkCancel,
    YesNo,
+   CustomOkCancel(String, String),
}

I tried to implement it but got stuck in Windows API.

I'm a little bit lost here. When building locally under Linux Mint 20.2 everything is fine. Building an AppImage via GitHub Actions using the ubuntu-18.04 image results in a crash when opening the file dialog:

Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Mint-Y/actions/16/image-missing.svg: Bildlader-Modul konnte nicht geladen werden: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /usr/lib/x86_64-linux-gnu/librsvg-2.so.2: undefined symbol: cairo_font_options_get_variations (gdk-pixbuf-error-quark, 5)

So the dialog seems to do something with icons and there is some incompabiility between libraries. I don't expect any solution from you, but maybe you have a better knowledge than me what causes the problem.

You can download the AppImage here: https://github.com/sourcebox/dfu-buddy/releases/tag/0.1.0-alpha2

RFD currently uses windows 0.33 which is now outdated. This will take a little work because the SetFileTypes API has changed.

This was attempted in #64.

The doc comment for FileDialog::set_parent says it supports mac and windows, but this doesn't seem to be the case.

I tried switching AsyncFileDialog to FileDialog in the winit example, and the file dialog did not attach to the window.

In file_dialog.rs, self.parent is only used for the AsyncFileDialog impls.

MacOS generally wants UI stuff to be run on the main thread. Is it possible to create a dialog on another thread then the main thread? If not is it possible to create it on the main thread the move it to a second thread and wait for the user response there? My use case requires awaiting a prompt repsonse without blocking the main thread.

It is a very large dependency and it should be an optional dependency that is activated by the feature for it. So if you just use the GTK support you don't build it.

Right now in v0.7.0 it is always included for linux/unix targets, which adds and builds approximately 21 unused crate dependencies even when using default-features = false.

Think all that is needed is to set the dependency to optional = true assuming the cfg for the feature does gate all of its use?

If I try to execute the command cargo run --example simple on Windows, no dialog is shown and the output is always The user choose: None.
This is because of the .set_directory(&"/") line, which messes things up. I did not investigate the exact reason, but I guess it has to do with that path being invalid under Windows.

This is a really minor thing but maybe it should be fixed so that newbie potential library users are not scared away from the lib.

Whenever the user cancels the Finder dialogue, the windows turns blank and remains behind. It only closes when the program stops running. This hasn't happened to me in Monterey, so again it could be a Ventura thing.

Hello,

The latest, 0.9.0 version of rfd fails to build on Windows 11. I believe I'm building with 0.9.0 on a Linux system at home and there's no problem, I would have to check. The last version, 0.8.4 compiles fine on the same system that causes 0.9.0 to fail.

Build Environment

• OS
  • Windows 11 Home Version 21H2
• Rust
  • stable-x86_64-pc-windows-gnu unchanged - rustc 1.61.0 (fe5b13d68 2022-05-18)
  • stable-x86_64-pc-windows-msvc unchanged - rustc 1.61.0 (fe5b13d68 2022-05-18)
• rfd
  • 0.9.0

Error

PS C:\Users\RFID\Desktop\Development\LISA> cargo build
   Compiling rfd v0.9.0
error: failed to run custom build command for `rfd v0.9.0`

Caused by:
  process didn't exit successfully: `C:\Users\RFID\Desktop\Development\LISA\target\debug\build\rfd-0842322a87b66bf1\build-script-build` (exit code: 101)
  --- stderr
  thread 'main' panicked at 'Couldn't to execute windres to compile "manifest.rc" into "C:\Users\RFID\Desktop\Development\LISA\target\debug\build\rfd-46a870fa0801e5af\out/libmanifest.a": program not found', C:\Users\RFID\.cargo\registry\src\github.com-1ecc6299db9ec823\embed-resource-1.7.2\src\windows_not_msvc.rs:34:23
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
PS C:\Users\RFID\Desktop\Development\LISA>

MessageDialog::show returns a bool but doesn't explain it.

PS: thanks for a great library!

@PolyMeilex,

congratulations for your excellent work with the rfd library.

Will save_file() be implemented in rfd for Wasm32?

Sorry if my question is stupid, but I’m only an average user (no coding abilities) and my question comes from ruffle-rs/ruffle#7596.

Many thanks for your help.

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.

Would it be possible? The naive approach of adding a Sync bound to DialogFutureType works and compiles (one windows), but obviously, external libraries, calling unsafe code, so I cannot be sure.

Gtk is a fallback for xdg portal anyway, we don't care about it much, so we can just replace it with CLI alternatives. Same for message dialogs. It would not be behind a feature flag, it would rather be a fallback for existing portal backend.

Those are also a part of most common flatpack runtimes so we should get a working message dialog even from a sandbox.

While using the GitHub CI, I found out that some Linux dependencies have to be installed:

• libpango1.0-dev
• libatk1.0-dev
• libgtk-3-dev

Please put this info somewhere in the README.

I encountered this error when testing Tauri's auto-updater which uses rfd's dialog, the ideal would be make it scrollable when the text is too long, and if possible, make the link is clickable and functioning.

Thanks in advance!

Whenever I (un)focus the file dialogue or move the windows around, I get +[CATransaction synchronize] called within transaction errors spammed to the console. This happens even with the sync dialogue. I haven't seen this happen in Monterey, so it could be a Ventura thing.

error[E0277]: the trait bound FileDialog: AsyncFilePickerDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:205:52
|
205 | AsyncFilePickerDialogImpl::pick_file_async(self.file_dialog)
| ------------------------------------------ ^^^^^^^^^^^^^^^^ the trait AsyncFilePickerDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

error[E0277]: the trait bound FileDialog: AsyncFilePickerDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:210:53
|
210 | AsyncFilePickerDialogImpl::pick_files_async(self.file_dialog)
| ------------------------------------------- ^^^^^^^^^^^^^^^^ the trait AsyncFilePickerDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

error[E0277]: the trait bound FileDialog: AsyncFolderPickerDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:218:56
|
218 | AsyncFolderPickerDialogImpl::pick_folder_async(self.file_dialog)
| ---------------------------------------------- ^^^^^^^^^^^^^^^^ the trait AsyncFolderPickerDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

error[E0277]: the trait bound FileDialog: AsyncFileSaveDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:241:50
|
241 | AsyncFileSaveDialogImpl::save_file_async(self.file_dialog)
| ---------------------------------------- ^^^^^^^^^^^^^^^^ the trait AsyncFileSaveDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

error[E0277]: the trait bound FileDialog: FilePickerDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:98:41
|
98 | FilePickerDialogImpl::pick_file(self)
| ------------------------------- ^^^^ the trait FilePickerDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

error[E0277]: the trait bound FileDialog: FilePickerDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:103:42
|
103 | FilePickerDialogImpl::pick_files(self)
| -------------------------------- ^^^^ the trait FilePickerDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

error[E0277]: the trait bound FileDialog: FolderPickerDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:108:45
|
108 | FolderPickerDialogImpl::pick_folder(self)
| ----------------------------------- ^^^^ the trait FolderPickerDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

error[E0277]: the trait bound FileDialog: FileSaveDialogImpl is not satisfied
--> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/rfd-0.7.0/src/file_dialog.rs:127:39
|
127 | FileSaveDialogImpl::save_file(self)
| ----------------------------- ^^^^ the trait FileSaveDialogImpl is not implemented for FileDialog
| |
| required by a bound introduced by this call

For more information about this error, try rustc --explain E0277.
error: could not compile rfd due to 8 previous errors
warning: build failed, waiting for other jobs to finish...
error: failed to compile cargo-ui v0.3.1, intermediate artifacts can be found at /data/data/com.termux/files/usr/tmp/cargo-installEOnLnG

Caused by:
build failed

Hello,
If set_directory() path doesn't exist then the dialog doesn't show up, at least on Windows.
Since rfd returns an Option instead of a Result users may assume that the dialog cannot fail, so I think it could be useful to check if the folder exist before.

Cheers.

This code:

FileDialog::new()
        .set_directory(PathBuf::from("C:\\"))
        .pick_folder()

opens my Documents directory for some reason

rfd 0.2.0

When clicking on the Save button in a Windows dialog created by AsyncFileDialog::pick_folder, the dialog remains open and the Future does not complete. This issue does not happen with pick_file, and is also not present on macOS.

Hello 👋

I have very little experience with Rust, so I apologize in advance if I'm going to say dumb things.

I come from this Tauri bug I have reported this afternoon, is it possible to select multiple directory at once using this library?

Hello, thank you for the great library. It's working really well but I'm kind of having a problem. I have this case where it would be much more efficient for me if rfd provided me with an iterator over the picked files rather than immediately allocating Vec for me (which is what rfd::FileDialog::pick_files does). For example in the Linux GTK3 backend I can see that there is actually this internal iterator which seems to be just what I need. It is then abstracted away with this collect:
https://github.com/PolyMeilex/rfd/blob/master/src/backend/gtk3/file_dialog/dialog_ffi.rs#L136
I can imagine there is many cases where you simply want to iterate over the results of pick_files once, so you don't really need to have it in a Vec.
Personally I'd change pick_files to return an Iterator instead because it really encourages efficiency: if you just want to iterate over it, you can do that but if you really want it to be in a Vec, you need to call collect yourself. I.e. more control. But I suppose it would be too much of a breaking change so maybe that should be pick_files_iter?
I wish I could implement this but I can only test the Linux implementation. I've done some initial work here:
wooster0@9036798
The Windows and macOS backends were pure guesswork and most likely don't work. How do you test them?

Additionally, adding the top-level pick_files_iter might also involve some challenges. I've come across some the size for values of type X cannot be known at compilation time errors trying to do that.

I would like your input on this. If you don't approve this, feel free to close it.