tauri-apps / tauri-apps/plugins-workspace
[FEATURE] "mandatory" file picker.
- Dominant language
- Rust
- Stars
- 1.8k
- Forks
- 602
- Avg merge
- 4d 14h
- Merged PRs (30d)
- 9
Description
### Describe the problem
There is this behaviour I see in some windows apps where, when a popup or file/folder picker appears, the parent window that spawned this popup/dialog cannot be interacted with at all until that popup is either closed or has a valid option selected by the user.
I tried to use `app_handle.dialog().file().blocking_pick_files()` on my frontend buttons, but it immediately makes the entire tauri app be flagged as "not answering". And using the standard `pick_files()` makes it possible to spawn MULTIPLE file pickers, and user still being able to interact with the main window overall.
### Describe the solution you'd like
This would be useful on instances where the app should still run, but not be interactable, for now, the only alternative I see are some workarounds like disabling Pointer-Events, Keyboard shortcuts and such in the whole application until the filePicker is solved.
Some examples to illustrate better what I was looking for in the Tauri library to do.
- In the [microsoft learn page for the MessageBox Classes](https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.messagebox?view=windowsdesktop-10.0), there is this description
> It is a modal window, blocking other actions in the application until the user closes it.
- If you go in basically any website inside chrome (tested now with Twitter), and click on something that opens a filePicker popup, when you try to click on the browser again, you CANNOT until you solve that filePicker popup. (That's the EXACT behaviour I want to replicate in my apps)
### Alternatives considered
_No response_
### Additional context
_No response_
Contributor guide
Research direction
Start by comparing the mentioned blocking_pick_files() and pick_files() APIs and how each affects the Tauri app. Define the desired modal behavior across file and folder pickers, then verify that the parent window cannot be interacted with while the picker remains responsive and that multiple pickers cannot be spawned.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- desktop
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100