iced
iced copied to clipboard
iced-rs
rfd for file dialogs
@PolyMeilex I saw that you're a frequent contributor here. Is there a chance that your rfd crate can be used for file dialogs?
Yes it can be. I use rfd in my iced app https://github.com/harmony-development/Crust/blob/master/src/screen/mod.rs#L1336.
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
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.
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.
Are there any examples on how to integrate rfd with iced with #1019 merged?
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.
@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 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 withiced? Do I have to use the async versions to make them work? Would it be better to wait untilwinitis 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
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
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.
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.
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.
The main disadvantage with xdg-portal is that it doesn't support filters, at least according to the rfd docs.
The main disadvantage with
xdg-portalis that it doesn't support filters, at least according to therfddocs.
Yeah that's an overnight, starting directory is GTK only, filters are supported, docs have a mistake in the table.