Asynchronous file dialogs

[btzy]

It is perhaps time to revisit designing an asynchronous API.

Some considerations:

• Do we want a callback-based API (e.g. like Cocoa's native API or a polling-based API (closer to GTK/Portal's native API)?
• How can the user perform non-busy waiting?
• Should this be built into a separate static/shared library (since very few applications will want to call both sync and async functions)?

Note 1: Asynchronous file dialogs are about calling an NFD API function that shows a file dialog window, but returns before the dialog is completed. It is not about multithreading or thread-safe API calls - you are still expected to call the async functions from the main thread.

Note 2: Even after this is merged, async support will be considered unstable for a while.

Related: #64

[eduardodoria]

The default behavior of NFD seems different from other natives apps on Linux.

This my app:

Gravacao.de.tela.de.2025-02-27.13-15-25.webm

This is a native app:

Gravacao.de.tela.de.2025-02-27.13-23-42.webm

I'm having trouble to open it async like #64 and keep window always on top. I can't replicate this behavior to not lock thread and still always on top.

[btzy]

I don't think you can currently do this in NFDe unfortunately. I assume you are able to keep the dialog window always on top when directly calling NFD APIs (so you must be providing NFDe with the "parent window handle"), but when you wrap the call in a std::async or run it in another thread like on #64, the dialog window won't stay on top?

[eduardodoria]

Yes, If I directly call using NFD APIs it stay on top, but lock thread of main windows, cause this warning I showed on first video. If I call using std::async, it not show wanings, but not always on top.

[btzy]

Thanks for the clarification. This seems to mean that spawning the dialog window on a separate thread will not have the "stay on top" behaviour, and so any proper solution needs to work on a single thread. This will be somewhat difficult to do properly in a cross-platform manner (but maybe not impossible), because we need to be able to yield control back to the main window, but set up a listener/callback so that we can be notified when the user selects a file.