search

iced-rs / iced

A cross-platform GUI library for Rust, inspired by Elm
https://iced.rs
MIT License
24.08k stars 1.12k forks source link

rfd for file dialogs #1002

Open sourcebox opened 3 years ago

sourcebox commented 3 years ago

@PolyMeilex I saw that you're a frequent contributor here. Is there a chance that your rfd crate can be used for file dialogs?

yusdacra commented 3 years ago

Yes it can be. I use rfd in my iced app https://github.com/harmony-development/Crust/blob/master/src/screen/mod.rs#L1336.

PolyMeilex commented 3 years ago

If you are asking if it can be used at the moment, then sure, it can easily be done.

If you are asking about tighter integration, for example proper setting of parent window, that would probably require integration inside iced, because we need window handle for that. I'm open to working on something like that, if there is enough interest from users and from @hecrj himself

sourcebox commented 3 years ago

I think file dialogs were requested several times in the past. To me, rfd is the best existing crate for this I'm aware of. This is because it's pure Rust and so allows cross-compilation (e.g. for ARM Macs) in an easy way.

hecrj commented 3 years ago

rfd looks great!

We could expose a file-dialog feature to expose additional actions related to file dialogs once the new Command implementation lands (see #1019).

Since the new Command actions are processed in the event loop, at the shell level, it should be easy to obtain the window handle for proper integration, without actually exposing it in iced.

PolyMeilex commented 3 years ago

1019 sounds great 👍

anarsoul commented 2 years ago

Are there any examples on how to integrate rfd with iced with #1019 merged?

PolyMeilex commented 2 years ago

Are there any examples on how to integrate rfd with iced with #1019 merged?

1019 does not change anything for end-users it's just a change that makes it easier to integrate rfd directly into iced, and that is not implemented. So yeah for now you can treat rfd like any other async job.

sourcebox commented 2 years ago

@PolyMeilex Since winit 0.26 was integrated to egui, the dialogs work fine there even on macOS (they were freezing before). What is the situation regarding this here with iced? Do I have to use the async versions to make them work? Would it be better to wait until winit is also updated?

PolyMeilex commented 2 years ago

@PolyMeilex Since winit 0.26 was integrated to egui, the dialogs work fine there even on macOS (they were freezing before). What is the situation regarding this here with iced? Do I have to use the async versions to make them work? Would it be better to wait until winit is also updated?

Good to know that my fix was published already 🎉 But iced has its own fork of winit, so it has to be rebased. The update of winit is also blocking my wgpu PR #1164

Alch-Emi commented 2 years ago

Working on designing an API for this in my fork. It might turn into a PR once I'm a little happier with the shape of it

jpercyasnet commented 1 year ago

When reviewing rfd, I noticed that it uses gtk3. If we are talking pure rust, gtk3 is not pure rust. I would suggest converting the gtk3 to something simple like https://github.com/Barugon/egui_file.

setzer22 commented 1 year ago

There's the option to use the xdg-portal backend which is pure-rust and much simpler than the GTK-3 one. It has the advantage of using your desktop environment's native file picker, which is nicer.

PolyMeilex commented 1 year ago

When reviewing rfd, I noticed that it uses gtk3. If we are talking pure rust, gtk3 is not pure rust. I would suggest converting the gtk3 to something simple like https://github.com/Barugon/egui_file.

xdg-portal backend depends only on std (so libc in extent) you can't get purer than that, it also has the least unsafe lines of all platforms (as all others have to call into FFI), using something like egui_file is not that simple, it will not work in sandboxed environment, GTK3 (with xdg-portal code backed into it), and RFD's pure rust xdg-portal backend can both handle that case.

That being said it could act as a fallback to our backend, if someone for example is running some kind of dbus-free system and treats xdg-portal as a bloat, then egui could kick in as a fallback.

sourcebox commented 1 year ago

The main disadvantage with xdg-portal is that it doesn't support filters, at least according to the rfd docs.

PolyMeilex commented 1 year ago

The main disadvantage with xdg-portal is that it doesn't support filters, at least according to the rfd docs.

Yeah that's an overnight, starting directory is GTK only, filters are supported, docs have a mistake in the table.