Consider comparison of other native file dialog libraries?

[jcbhmr]

in my cursory google searching, i was able to to find the interesting https://sourceforge.net/projects/tinyfiledialogs/ project that seems to be similarish to this project. i'd be interested in seeing a comparison paragraph similar to how the current readme describes some differences between it and the original nativefiledialog library.

why not leave such comparisons as an exercise to the reader? because a reader may not be as "in-tune" with the strengths and weaknesses of your library. you wrote it; ❤️ tell me how cool it is! 😊

other cool file dialog libraries i found

https://github.com/samhocevar/portable-file-dialogs

• c++11
• header only
• sync or async

https://github.com/PolyMeilex/rfd

• rust
• wasm support with html-based <input> popup
• sync or async

[btzy]

Let me think more about this, but I'm leaning towards a no. There is already a list of features at the top of the readme, and I'm not sure if we really need explicit comparison with other libraries.

Firstly, other libraries can evolve, leaving the comparison out of date. Secondly, performing a comparison of my own library is not going to be trustworthy - I (and I think most people) will prefer to trust an independent comparison by a third party is not affiliated with any such library. Finally, I'm not too sure about the ethics of pointing out all the flaws of other open source projects - this is not a competition, and each of the authors of those other file dialog projects have spent their free time building it and sharing it with the world. I have left a couple of comments some of the issues on the original NFD library detailing the way I fixed some things in my library (though it seems that that library is sort of abandoned).

On an unrelated note, I noticed that tinyfd and pfd prefer spawning a separate process to open the dialog (e.g. AppleScript, KDialog, and Zenity) but NFDe stays away from those things and prefers calling the native API in-process.

[jcbhmr]

Would this be something you'd consider putting in the wiki given your prior comments in #104 about the wiki being more "unofficial" since it lists other projects?