otomatalabs/furnace
8
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

add modified version of Native File Dialog

Browse source 
it will replace portable-file-dialogs on Windows, and perhaps in
the rest of operating systems (maybe not Linux) as well.
This commit is contained in:
tildearrow 2022-06-17 00:02:29 -05:00
parent ad5072dad6
commit d5d381328b
19 changed files with 2796 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

39
extern/nfd-modified/docs/build.md vendored Normal file
View file

@ -0,0 +1,39 @@
# Building NFD #
Most of the building instructions are included in [README.md](/README.md). This file just contains apocrypha.
## Running Premake5 Directly ##
*You shouldn't have to run Premake5 directly to build Native File Dialog. This is for package maintainers or people with exotic demands only!*
1. [Clone premake-core](https://github.com/premake/premake-core)
2. [Follow instructions on how to build premake](https://github.com/premake/premake-core/wiki/Building-Premake)
3. `cd` to `build`
4. Type `premake5 <type>`, where <type> is the build you want to create.
### Package Maintainer Only ###
I support a custom Premake action: `premake5 dist`, which generates all of the checked in project types in subdirectories. It is useful to run this command if you are submitting a pull request to test all of the supported premake configurations. Do not check in the built projects; I will do so while accepting your pull request.
## SCons build (deprecated) ##
As of 1.1.6, the deprecated and unmaintained SCons support is removed.
## Compiling with Mingw ##
Use the Makefile in `build/gmake_windows` to build Native File Dialog with mingw. Mingw has many distributions and not all of them are reliable. Here is what worked for me, the primary author of Native File Dialog:
1. Use mingw64, not mingw32. Downloaded from [sourceforge.net](https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe/download).
2. When prompted in the intsaller, install the basic compiler and g++.
3. Add the installed bin dir to command prompt path.
4. Run `set CC=g++` to enforce `g++` instead of the default, `cc` for compiling and linking.
5. In `build/gmake_windows`, run `mingw32-make config=release_x64 clean`. Running clean ensures no Visual Studio build products conflict which can cause link errors.
6. Now run `mingw32-make config=release_x64`.
The author has not attempted to build or even install an x86 toolchain for mingw.
If you report an issue, be sure to run make with `verbose=1` so commands are visible.
## Adding NFD source directly to your project ##
Lots of developers add NFD source directly to their projects instead of using the included build scripts. As of 1.1.6, this is an acknowledged approach to building. Of course, everyone has a slightly different toolchain with various warnings and linters enabled. If you run a linter or catch a warning, please consider submitting a pull request to help NFD build cleanly for everyone.

25
extern/nfd-modified/docs/contributing.md vendored Normal file
View file

@ -0,0 +1,25 @@
# Pull Requests #
I have had to turn away a number of pull requests due to avoidable circumstances. Please read this file before submitting a pull request. Also look at existing, rejected pull requests which state the reason for rejection.
Here are the rules:
- **Submit pull requests to the devel branch**. The library must be tested on every compiler and OS, so there is no way I am going to just put your change in the master before it has been sync'd and tested on a number of machines. Master branch is depended upon by hundreds of projects.
- **Test your changes on all platforms and compilers that you can.** Also, state which platforms you have tested your code on. 32-bit or 64-bit. Clang or GCC. Visual Studio or Mingw. I have to test all these to accept pull requests, so I prioritize changes that respect my time.
- **Submit Premake build changes only**. As of 1.1, SCons is deprecated. Also, do not submit altered generated projects. I will re-run Premake to re-generate them to ensure that I can still generate the project prior to admitting your pull request.
- **Do not alter existing behavior to support your desired behavior**. For instance, rewriting file open dialogs to behave differently, while trading off functionality for compatibility, will get you rejected. Consider creating an additional code path. Instead of altering `nfd_win.cpp` to support Windows XP, create `nfd_win_legacy.cpp`, which exists alongside the newer file dialog.
- **Do not submit anything I can't verify or maintain**. If you add support for a compiler, include from-scratch install instructions that you have tested yourself. Accepting a pull request means I am now the maintainer of your code, so I must understand what it does and how to test it.
- **Do not change the externally facing API**. NFD needs to maintain ABI compatibility.
## Submitting Cloud Autobuild systems ##
I have received a few pull requests for Travis and AppVeyor-based autobuilding which I have not accepted. NativeFileDialog is officially covered by my private BuildBot network which supports all three target OSes, both CPU architectures and four compilers. I take the view that having a redundant, lesser autobuild system does not improve coverage: it gives a false positive when partial building succeeds. Please do not invest time into cloud-based building with the hope of a pull request being accepted.
## Contact Me ##
Despite all of the "do nots" above, I am happy to recieve new pull requests! If you have any questions about style, or what I would need to accept your specific request, please contact me ahead of submitting the pull request by opening an issue on Github with your question. I will do my best to answer you.