Martin Gerhardy
Just a minor thing, but a huge outcome. All the other jni related functions already have those flags, but the nativeInit function lacks them - so it might be stripped away.
In extremely rare cases, probably due to misconfigured drivers, one might
see this happen, and rather than terminate the process, we try to recover
by reporting an error to the app.
Fixes Bugzilla #3068.
Note that extra steps must be taken when using glReadPixels to read the contents of the main OpenGL ES framebuffer on iOS, if multisampling is used. See the OpenGL ES section of README-ios.md for details.
There are platforms it isn't implemented on (and currently can't be
implemented on!), and there's currently no way for an app to know this.
This shouldn't break ABI on apps that moved to a revision between 2.0.3 and
2.0.4.
This relies on a successful SDL_Init(SDL_INIT_VIDEO) to work, since it's
silly to reproduce all the Xinerama/XRandR code in the message box parts. If
X11 is available but SDL hasn't been initialized, the message box will center
in the primary screen, which will be positioned weirdly on multi-head setups,
but this should fix the most significant common case.
Author: Benoit Pierre <benoit.pierre@gmail.com>
Date: Fri Jul 3 02:17:10 2015 +0200
fix 14dd48ae5bc43b61b2a0dd0b3177d22edec707ef regression
The window manager detection code in X11_HasWindowManager does not work
with Awesome (http://awesome.naquadah.org/). Remove it, and reuse the
result of the more correct checks in X11_CheckWindowManager.
Elise Maurer
When inputting text, dead-keys are currently not handled correctly on Windows with the latest SDL2 tip as well as the 2.0.3 release.
Using a French AZERTY keyboard, when I type the `^` key followed by `e` key to compose the `` character, I erroneously get two SDL_TEXTINPUT events, one with the `^` character and one with the `e` character.
I've looked at the history for SDL_windowsevents.c and there's been some back-and-forth with several methods for handling text input:
* r8142 removed any handling of WM_CHAR because keyboard input was being handled through WM_KEYDOWN along with ToUnicode since r7645.
* But using ToUnicode actually breaks dead-keys (googling for "ToUnicode dead keys" reports many horror stories of people trying to work around that and failing).
* It seems like r7645 introduced a double-fix: it fixed WM_CHAR to properly handle Unicode, and also (unnecessarily?) added text input handling to WM_KEYDOWN. Later, r8142 removed the WM_CHAR stuff instead of the WM_KEYDOWN stuff.
The attached patch restores handling of text input through WM_CHAR and removes it from WM_KEYDOWN. I've tested it with French, English and Russian layouts and it seems to do its job. Obviously, with such matters, it's still a risky change.
