Tue, 14 May 2019 07:55:42 -0700[SDL] ios Touch Fix.
Sam Lantinga <slouken@libsdl.org> [Tue, 14 May 2019 07:55:42 -0700] rev 12728
[SDL] ios Touch Fix.

Sat, 11 May 2019 12:41:21 -0400Patched to compile.
Ryan C. Gordon <icculus@icculus.org> [Sat, 11 May 2019 12:41:21 -0400] rev 12727
Patched to compile.

Thu, 09 May 2019 12:09:45 +0100Emscripten: Use EMSCRIPTEN_EVENT_TARGET_*
Charlie Birks <charlie@daftgames.net> [Thu, 09 May 2019 12:09:45 +0100] rev 12726
Emscripten: Use EMSCRIPTEN_EVENT_TARGET_*

Thu, 09 May 2019 12:09:40 +0100Emscripten: Switch from canvas[XY] to target[XY]
Charlie Birks <charlie@daftgames.net> [Thu, 09 May 2019 12:09:40 +0100] rev 12725
Emscripten: Switch from canvas[XY] to target[XY]
Allows mouse/touch events to work on non-default canvases

Thu, 09 May 2019 12:09:34 +0100Emscripten: Store canvas id in WindowData
Charlie Birks <charlie@daftgames.net> [Thu, 09 May 2019 12:09:34 +0100] rev 12724
Emscripten: Store canvas id in WindowData
Also replace all hardcoded uses of "#canvas" or NULL

Thu, 25 Apr 2019 14:17:07 -0700Fixed bug 4608 - Android: not getting SDL_WINDOWEVENT_FOCUS_GAINED on start of our app
Sam Lantinga <slouken@libsdl.org> [Thu, 25 Apr 2019 14:17:07 -0700] rev 12723
Fixed bug 4608 - Android: not getting SDL_WINDOWEVENT_FOCUS_GAINED on start of our app

Dan Ginsburg

I've seen this on several devices including Moto Z running Android 7 and a Snapdragon 845 running Android 9.

What happens is as follows:

SDLActivity.onWindowFocusChanged(true) happens pretty early on, but it's before we've done SDL_CreateWindow and so Android_Window is 0x0 thus this message does not get sent:

JNIEXPORT void JNICALL SDL_JAVA_INTERFACE(nativeFocusChanged)(
JNIEnv *env, jclass cls, jboolean hasFocus)
{
SDL_LockMutex(Android_ActivityMutex);

if (Android_Window) {
__android_log_print(ANDROID_LOG_VERBOSE, "SDL", "nativeFocusChanged()");
SDL_SendWindowEvent(Android_Window, (hasFocus ? SDL_WINDOWEVENT_FOCUS_GAINED : SDL_WINDOWEVENT_FOCUS_LOST), 0, 0);
}

SDL_UnlockMutex(Android_ActivityMutex);
}

When the window does get created, in Android_CreateWindow it does this:

window->flags &= ~SDL_WINDOW_RESIZABLE; /* window is NEVER resizeable */
window->flags &= ~SDL_WINDOW_HIDDEN;
window->flags |= SDL_WINDOW_SHOWN; /* only one window on Android */
window->flags |= SDL_WINDOW_INPUT_FOCUS; /* always has input focus */

/* One window, it always has focus */
SDL_SetMouseFocus(window);
SDL_SetKeyboardFocus(window);

The SDL_SetKeyboardFocus does send an SDL_WINDOWEVENT_FOCUS_GAINED message, but it gets eaten in SDL_SendWindowEvent because we've forced SDL_WINDOW_INPUT_FOCUS beforehand:

case SDL_WINDOWEVENT_FOCUS_GAINED:
if (window->flags & SDL_WINDOW_INPUT_FOCUS) {
return 0;
}
window->flags |= SDL_WINDOW_INPUT_FOCUS;
SDL_OnWindowFocusGained(window);
break;

I can fix the problem if I comment out this line from Android_CreateWindow:

window->flags |= SDL_WINDOW_INPUT_FOCUS; /* always has input focus */

I would propose that as a fix unless there is a reason not to.

Wed, 24 Apr 2019 20:28:21 +0100Remove duplicate case value SDL-1.2
Cameron Cawley <ccawley2011@gmail.com> [Wed, 24 Apr 2019 20:28:21 +0100] rev 12722
Remove duplicate case value

Wed, 24 Apr 2019 20:20:15 +0100Remove initial declaration from for loop SDL-1.2
Cameron Cawley <ccawley2011@gmail.com> [Wed, 24 Apr 2019 20:20:15 +0100] rev 12721
Remove initial declaration from for loop

Wed, 24 Apr 2019 12:53:15 -0700Fixed bug 4566 - Hot-plugging Bluetooth controller causes force-quit on Android
Sam Lantinga <slouken@libsdl.org> [Wed, 24 Apr 2019 12:53:15 -0700] rev 12720
Fixed bug 4566 - Hot-plugging Bluetooth controller causes force-quit on Android

Anthony @ POW Games

I tried adding different configChanges and sure enough, "navigation" worked! Now bluetooth controllers hot-plug nicely. So shall we add it as a default to the AndroidManifest.xml?

Funny that this is how this activity is described:

"navigation" The navigation type (trackball/dpad) has changed. (This should never normally happen.)

I think the reason behind this is because the bluetooth game controller I was testing doubles-up as a keyboard, which probably comes with a DPAD? It's a MOCUTE-032X_B63-88CE

Tue, 23 Apr 2019 16:57:34 -0700Don't redefine __SSE__ and related macros if they're already defined
Sam Lantinga <slouken@libsdl.org> [Tue, 23 Apr 2019 16:57:34 -0700] rev 12719
Don't redefine __SSE__ and related macros if they're already defined