Skip to content
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

set_directory and set_file_name weird behavior on Linux #35

Closed
lucasfernog opened this issue Dec 23, 2021 · 3 comments
Closed

set_directory and set_file_name weird behavior on Linux #35

lucasfernog opened this issue Dec 23, 2021 · 3 comments

Comments

@lucasfernog
Copy link
Contributor

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.

@PolyMeilex
Copy link
Owner

Hi!
Could you try master branch, I think I got the conditions right this time 🤞

@lucasfernog
Copy link
Contributor Author

Works fine now, thanks! I didn't know you were doing all the logic for us ❤️

@PolyMeilex
Copy link
Owner

I didn't know you were doing all the logic for us heart
Yeah, sadly it's probably the only way to hide platform specific details.

Thanks for the report! I'll release a patch release shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants