Try to use portals, and fall back on GTK about nativefiledialog-extended HOT 3 OPEN

Just to be sure I'm understanding you correctly, you want to have a check at runtime to decide whether to open a Portal or GTK dialog?

from nativefiledialog-extended.

Yes. Sorry, re-reading myself, I realize that this was pretty badly written

The functions could be implemented on your side with something like this:
(pseudocode, I know your API isn't exactly like that)

nfdresult_t NFD::openFile(NFD::UniquePathU8 outPath) {
	result = NFD::Portal::openFile(outPath)
	if (result == NFD_ERROR) {
		return NFD::GTK::openFile(outPath)
	} else return result;
}

But It'd also be fine for me if NFD::Portal::openFile() and NFD::GTK::openFile() were simply exposed to us, and we had the responsibility to implement the fallback (right now we have to choose between them at compile time with NFD_PORTAL)

from nativefiledialog-extended.

Thanks for the clarification.

It's a nice feature to have, and I'd be happy to accept a PR for such a feature (as long as it is possible at build time to select just a single implementation).

There's a different but related question, about whether it should be a hard loader error if the loader cannot find libdbus or libgtk at runtime. Your current proposal will be a hard error at load time, which I'm not sure is ideal. Preventing a hard loader error is usually achieved using dlopen() (as mentioned in mlabbe/nativefiledialog#42 and mlabbe/nativefiledialog#102), but it can probably be done more nicely on Linux by importing the functions from shared libraries as weak symbols (with #pragma weak or some attribute). This will allow you to run your binary even if one of libdbus or libgtk is missing. I'm not too sure whether such a distribution exists in practice though.

from nativefiledialog-extended.