Browsers don't have the functionality to fully support the generic
SDL_ShowMessageBox(), but this handles the likely most-common case.
Without this, you'd return immediately with a proper error result and no UI,
but probably no one checks that for SDL_ShowSimpleMessageBox. And if they
did: what would they do to handle this anyhow?
We'd need to lobby for an HTML spec of some sort that allows customizable
message boxes--that block!--to properly support SDL message boxes on
Emscripten, but this is probably Good Enough for now.
AudioQueues are available in Mac OS X 10.5 and later (and iOS 2.0 and later).
Their API is much more clear (and if you don't mind the threading tapdance
to get its own CFRunLoop) much easier to use in general for our purposes.
As an added benefit: they seemlessly deal with format conversion in ways
AudioUnits don't: for example, my MacBook Pro's built-in microphone won't
capture at 8000Hz and the AudioUnit version wouldn't resample to hide this
fact; the AudioQueue version, however, can handle this.
Generate the C protocol files from the protocol XML files installed by
wayland-protocols, and use them to implement support for relative pointer
motions and pointer locking.
Note that at the time, the protocol is unstable and may change in the future.
Any future breaking changes will, however, fail gracefully and result in no
regressions compared to before this patch.
Since we are loading shared objects dynamically, build our own version of the
core protocol symbols, so that we in the future can include protocol
extensions.
This will be used by Wayland compositors to match the application ID and
.desktop file to the SDL window(s).
Applications can set the SDL_VIDEO_WAYLAND_WMCLASS environemnt variable
early in the process to override using the binary name as a fallback.
Note that we also support the SDL_VIDEO_X11_WMCLASS in the Wayland
backend so that if a program correctly associated the desktop file with
the window under X11, only a newer SDL would be needed for it to work
under Wayland.
https://bugzilla.libsdl.org/show_bug.cgi?id=3376
Author: James Zipperer <james.zipperer@synapse.com>
Date: Sun Aug 21 01:19:19 2016 -0700
bugfix for controller / joystick add / remove being in the event queue at the same time
The repro steps were this:
1. run an sdl2 winrt/uwp app, on Win10, v10.0.10586.0 or higher
2. hide the cursor, via a call to SDL_ShowCursor(0)
3. make the Win10 game bar appear, by pressing the Windows + G hotkey
4. observe that the mouse cursor appears, in order to interact with the
game bar (this is expected behavior)
5. make the Win10 game bar disappear, either by pressing the Windows + G hotkey
again, or clicking somewhere in the app
EXPECTED RESULT: cursor disappears, as game bar disappears
ACTUAL RESULT: cursor didn't always disappear
