It's possible (likely!) someone could just pass a pointer returned by
SDL_GetError for one of these strings, but the message box code has to do a
ton of complicated stuff that might _also_ call SDL_SetError, so you could
end up with the string having different contents by the time you display it.
Just make a copy of the strings unconditionally at the start, so they're safe
no matter where they came from.
Fixes#10932.
I am confused by the "You have to manually edit this file" comment. Does it mean that it is expected to manually remove the previous `#define SDL_LEAN_AND_MEAN 0` ?
In any case I put this part of the change in a separate commit so that it can easily be reverted.
Some compositors may not implement commit-timing-v1 in addition to fifo-v1, at least not immediately, and Mesa doesn't require commit-timing for FIFO behavior. The fifo-v1 protocol alone is enough for the desired behavior.
Only check for fifo-v1 to enable Wayland by default.
This used to do different things for recording streams in different parts of
the codebase, not to mention two separate codepaths through
UpdateAudioStreamFormatsPhysical in any case. My hope is this should kill off
a few corner case bugs...for example, this one:
Fixes#8402.
This could happen if you call SDL_BindAudioStreams() when the subsystem isn't
initialized, and possibly in other corner cases.
Thanks to Qianxin CodeSafe Team, @QiAnXinCodeSafe, for discovering this issue!
Fixes#11643.
A property cleanup callback might end up trying to set other properties, so we don't want to have a lock held at that point.
Fixes an assertion in testprocess when cleaning up IO stream properties
Read-write locks are not recursive and can't be upgraded from one type to another, so it's not safe to lock the hash table and then call functions that operate on it. If you really want this functionality, we'd need to create unlocked versions of the hashtable functions and you would call those once you've taken a lock on the hashtable, and we'd have to assert that the operations you're doing are compatible with the type of lock you've taken.
All of that complicates working with hashtables, so if you need that type of access, you should probably just use external locking.
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.
This can be reverted if a toolchain arrives that can handle C99 features like
variables declared in the middle of a scope, but for now we literally can't
compile SDL3 for this platform.
Fixes#11243.
Unless there are pending client requested window coordinates, such as in the case where the position is set followed by immediately by entering fullscreen, prefer the true window coordinates as sent by the window manager to select a fullscreen display.
Fixes the case where, if the window manager moves an already maximized window to another display, the window would be made fullscreen on the wrong display since the last floating coordinates would be used.
The double quotes were passed literally to the zenity arguments which
resulted in the message box displaying literal `""` when no text was
given. The empty string is more logical in this case, e.g., the empty
title results in the message box having lesser height.
When no extra buttons are passed to zenity with `--question --switch`
arguments it fails to show anything, however, SDL3 still reports
success. To handle this case, we pass an additional "OK" button.
Ryan C. Gordon