File dialogs and drag-and-drop of files

[emilk]

Tracking issue for

• File browser dialog for native (rfd now works since egui_glium: run app code outside event loop to fix file dialogs #631)
• File browser dialog for egui_web ("Select a file to upload")
• Drag-and-drop files onto egui_web and egui_glium` (Drag and drop files into egui_glium and egui_web #637)

[DrOptix]

I would like to contribute on this one. Going with something based on std::fs it would be consistent maybe except for egui_web.

On the other hand if we go with platform specific dialogs then that would show a familiar open dialog to the user.

• On Windows we can use Win32 API GetOpenFileNameW and GetSaveFileNameW.
• For Linux, here I think there is no standard file open dialog. I need to study. Currently I'm using KDE, but I have a mix of file dialogs from KDE and Gnome, I guess it depends on with which toolkit the app was built.
• On MacOS I have no idea, but I expect the situation to be similar as on Windows.

Maybe we should just go with this native-dialog crate?

[emilk]

If opening a file dialog on web is easy then maybe it can just be added to native-dialog instead (i.e. add a web-sys backend to native-dialog). The less code in this repository the better!

[vihdzp]

I should mention: I tried using native-dialog on Windows in a Bevy+egui application. About half of times, the dialogs failed with ImplementationError("CoInitializeEx"). I haven't yet filed an issue over there, as I need more testing to figure out what's going on, but it might be something worth being wary of.

[OvermindDL1]

About half of times, the dialogs failed with ImplementationError("CoInitializeEx").

For note, this is caused by the windows COM, it has to be initialized in either, essentially, single-threaded or multi-threaded mode, however some COM objects only work properly in one mode or the other (usually sound annoyingly, needs multithreaded), and dragging and dropping with 'extended' clipboard attributes is one such annoyance (needs single-threaded).

To see details about the issue and how winit deals with it then see: rust-windowing/winit#1255

But in short, if you don't need extended clipboard attributes (OLE Clipboard rather than standard clipboard) then drop the OLE stuff and it would work regardless, otherwise you have to discard drag/drop when CoInitializeEx is in the wrong mode.

[CjS77]

If you want to use native windows, perhaps using this crate is the way to go. Then you don't need to add anything here, or perhaps at most, a very thin wrapper.

[kellpossible]

Using native-dialog in a new thread upon button click, disabling the ui while waiting for result, using crossbeam-channel to send the result back to the ui seems to be working pretty well for me at least on linux. Still figuring out how to make it more re-usable, perhaps something to share.

[kellpossible]

Here was my first stab at it in a crate: https://crates.io/crates/im-native-dialog

[sourcebox]

I'd like to use the rfd crate to open a file dialog. This crate offers a pure Rust solution and an async mode, which is required to work in macOS. It is shown in an example here:

Example async code

Im my application, the dialog should open after pressing a button.

Where I'm struggling is how to integrate this into egui. I guess there has to be some executor and other stuff. My knowledge of Rust and async is still not sufficient to get this running, so any help would appreciated.

[vihdzp]

I'd like to use the rfd crate to open a file dialog. This crate offers a pure Rust solution and an async mode, which is required to work in macOS. It is shown in an example here:

I couldn't get async to work with my egui integration (bevy). Instead, what I did was make a synchronous flie dialog that was guaranteed to run on the main thread. I did this by putting its code in a system taking in a !Send resource. You might want to try that out instead.

[sourcebox]

Some good news: I was able to get rfd working with async at least in macOS and Linux. Can't do any Windows testing at the moment though. I used the demo code with minimal changes. The trickiest part was to get the selected file back to the application because self can't be accessed inside the async context. So I used an mpsc channel to get this working.

[imaitland]

@sourcebox could you share what you did?

[sourcebox]

Sure. My project is not published yet, so I tried to extract the relevant parts. By doing this, it's possible that I introduced some errors or forgot something.

pub enum Message {
    FileOpen(std::path::PathBuf),
    // Other messages
}

pub struct App {
    message_channel: (
        std::sync::mpsc::Sender<Message>,
        std::sync::mpsc::Receiver<Message>,
    )
}

impl Default for App {
    fn default() -> Self {
        Self {
            message_channel: std::sync::mpsc::channel(),
        }
    }
}

impl epi::App for App {
    fn update(&mut self, ctx: &egui::CtxRef, frame: &mut epi::Frame<'_>) {
        // This is important, otherwise file dialog can hang
        // and messages are not processed
        ctx.request_repaint();

        loop {
            match self.message_channel.1.try_recv() {
                Ok(message) => {
                    // Process FileOpen and other messages
                }
                Err(_) => {
                    break;
                }
            }
        }

        egui::CentralPanel::default().show(ctx, |ui| {
            let open_button = ui.add(egui::widgets::Button::new("Open...");

            if open_button.clicked() {
                let task = rfd::AsyncFileDialog::new()
                    .add_filter("Text files", &["txt"])
                    .set_directory("/")
                    .pick_file();

                let message_sender = self.message_channel.0.clone();

                execute(async move {
                    let file = task.await;

                    if let Some(file) = file {
                        let file_path = std::path::PathBuf::from(file.path());
                        message_sender.send(Message::FileOpen(file_path)).ok();
                    }
                });
            }
        });
    }
}

fn execute<F: std::future::Future<Output = ()> + Send + 'static>(f: F) {
    std::thread::spawn(move || {
        futures::executor::block_on(f);
    });
}