The syntax errors in the enum lists tell us that no one ever actually
compiled this `WINVER < _WIN32_WINNT_VISTA` fallback path. 2f5bc17 made
it increasingly unlikely for retro Windows builds to hit this path by
adding a new set of `WINVER` override rules to `SDL_windows.h` that
check for the presence of certain headers. `HAVE_MMDEVICEAPI_H` in
particular will be `#define`d for any CMake build with a ≥Vista-era
SDK, such as Visual Studio 2017's `v141_xp` toolset that 2f5bc17
targeted, and it's also unconditionally defined in the default
`SDL_build_config_windows.h` configuration used by the ready-made
Visual Studio project.
These fixes work for a XP-era configuration that undefines all of the
`HAVE_*_H` macros and `SDL_VIDEO_RENDER_D3D12` to make `SDL_windows.h`
fall through to the `#define _WIN32_WINNT _WIN32_WINNT_WINXP` case, on
both Visual Studio 2022 and Visual Studio 2017's `v141_xp` toolset.
This correctly sets the xdg portal fields for targeting a specific
new filename or existing file.
"current_name" sets the dialogs placeholder name.
"current_file" targets an existing file.
"current_folder" for when the target is a folder.
macOS sends a focus loss event when the dialog is created, which causes SDL
to try to minimize the window, which confuses the entire system. So in this
special case, don't do the minimization.
Fixes#13168.
Otherwise the window won't have focus until you click on it again. Calling
makeKeyAndOrderFront isn't enough to fix it, either.
This trick comes from a similar problem we solve in our
applicationDidFinishLaunching implementation: activate (give app focus to) the
system Dock, as something that definitely exists that isn't us and is harmless
to activate, and then activate us right afterwards. This unconfuses whatever
is getting confused inside Cocoa.
Fixes#12684.
So something like "index.pb" will now accept any file with a ".pb" extension,
to make macOS happy. This seems like a reasonable tradeoff.
Other minor cleanups.
Fixes#12778.
We require at least Xcode 12.2 and macOS SDK 11 to build. We support deploying to macOS 10.13, iOS 11.0, and tvOS 11.0.
This cleans up the code significantly
The Windows implementation of dialogs use the Win32 API, which expects the file filters to have null bytes as separator, and two null bytes at the end of the filter list. To help with string manipulation, the internal code uses 0x01 bytes instead of null bytes, and converts all 0x01 bytes into null bytes at the last moment. If someone decides to put two consecutive 0x01 bytes in their filter names, the code might mistakenly pick them up and convert them to null bytes, leading to Windows failing to pick up later filters. In practice, this is probably not so bad, since it requires someone to have control over file filters already, and allows at most ignoring the following file filters. It is also unlikely to happen by accident since 0x01 is not printable. This commit fixes that by replacing all the 0x01 bytes with the space character.
For some obscure reason I can't remember, I had made it so the suffix would be added only if the filter list was empty. That isn't the expected behavior and caused a mishandling of memory on Windows, which requires a two-null-bytes suffix.
Creating `argv` for zenity means we don't have to pass the building
blocks between threads which allows us to avoid deep copying some nested
structures. It also allows us to fail earlier in case of problems with
building the argument vector.
SDL properties passed to the `SDL_Zenity_ShowFileDialogWithProperties`
may be destroyed/modified immediately upon the function return.
Therefore, we must copy all the strings and structures passed via
pointers; otherwise, the `SDL_ZenityFileDialog` thread attempting to
read them will cause data race.
We require stdbool.h in the build environment, so we might as well use the plain bool type.
If your environment doesn't have stdbool.h, this simple replacement will suffice:
typedef signed char bool;
