-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Update file dialog example to be non-blocking. #5697
base: master
Are you sure you want to change the base?
Conversation
* the button is disabled while picking. * the main windows is responsive while picking - you can still drag files onto it. * the result of a pick is recorded and kept in the state as before.
…c::Mutex. * std::sync::Mutex is disallowed by clippy config.
de79199
to
e3d9d53
Compare
This is my first PR for egui, be gentle 😄 |
Also, I know this is just an example, but perhaps after merging this you might be interested in a PR to move the I note that other GUI frameworks I've used have 'rfd' features and similar APIs. |
I think it would be hard to implement this in a way that covers all the use cases of egui. For example, on wasm you can't spawn threads, so you have to use async, and then in rfd you have to pick which async backend you're using (async-std or tokio). Then there's the game engines and such. There are a couple of file pickers implemented as egui widgets instead of using rfd, as third-party crates. They are listed in the wiki. |
Also, I know this is just an example, but perhaps after merging this you might be interested in a PR to move the I note that other GUI frameworks I've used have 'rfd' features and similar APIs.
Yes, I understand that there's various backends for async and limitations with wasm. I feel it would still be ok to provide solution for the common native desktop use-case however, along with appropriate module documentation containing links to the wiki of course. This feels like it would serve the community better rather than requiring each egui developer to implement, test and debug their own API for a common use-case no? |
IMO this should supplement the existing blocking example, possibly as a button indicating a blocking dialog and another indicating non-blocking. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The blocking rfd
calls need to be on the main thread: https://docs.rs/rfd/latest/rfd/#macos-non-windowed-applications-async-and-threading
To get non-blocking file dialogs, you should use the async versions instead.
In any case, I'd like to keep the original example simple. If you want to make an async version, I suggest you create a separate example for it.
This PR updates the file dialog example to be non-blocking, additionally:
The result of a pick is recorded and kept in the state as before.
Video:
https://github.com/user-attachments/assets/29dd4cd9-b769-44f2-abe2-bd533728cdba
Related issues:
Related discussions:
Native file/directory picker #987 (comment)
How to avoid RFD file dialogs hanging egui? #5621
I have followed the instructions in the PR template