"Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'backgroundWindows not nil in enterFullScreenTransitionWithOptions:animated:activatingIt:'"
To reproduce this, run testsprite2, press Alt-Enter once, again while it's animating to fullscreen, and then again while it's animating out of fullscreen.
philhassey
Overview: While SDL_SetTextInputRect works perfectly to move my window out of the way of the virtual keyboard using SDL2/Android, on iOS this function has no effect.
Steps to Reproduce: Call SDL_SetTextInputRect with a rect near the bottom of the screen before calling SDL_StartTextInput.
Actual Results: The iOS virtual keyboard is displayed after calling SDL_StartTextInput, but the screen is not shifted to reveal the TextInputRect region.
Expected Results: The screen should be shifted to reveal the TextInputRect region (like with SDL2/Android.)
This patch implements SDL_SetTextInputRect for uikit/iOS.
It sets up notification handlers to respond to changes in the display of the keyboard. These handlers then change the frame of the view so it is moved out of the way of the keyboard as per SetTextInputRect.
This fixes behavior with the new Mac OS X fullscreen space code, as well as improve behavior on Linux desktops.
The default for normal fullscreen mode is still to minimize because we're likely doing a mode switch and don't want to stick around as a borderless window in the background.
I still haven't figured out why my application is being minimized when I try to raise, it but my previous workaround is causing issues.
For now the correct way to raise and/or restore the window is as follows:
if ( !(SDL_GetWindowFlags( window ) & SDL_WINDOW_MINIMIZED) )
{
SDL_RaiseWindow( window );
}
if ( SDL_GetWindowFlags( window ) & SDL_WINDOW_MINIMIZED )
{
SDL_RestoreWindow( window );
}
I will investigate the window state change rules more fully in the future.
CR: Alfred Reynolds
When we get a kCGEventTapDisabledByTimeout or
kCGEventTapDisabledByUserInput, the event tap would perform an invalid
memory access. void pointers are so fun.
This code only runs if you explicitly build with SDL_MAC_NO_SANDBOX.
Patrice Mandin
I encountered a problem trying to load a 8-bit paletted BMP file using SDL. This file was generated using GIMP 2.8. It has a big BITMAPINFOHEADER (0x6c bytes for biSize field), and thus the palette is incorrectly setup.
Lorenzo Pistone
this patch adds support for the horizontal wheel in Windows. It is shamelessly copied off the vertical wheel code, but I guess that that is a value added in consistency.
Thanks to Denis Bernard!
Also, changed the Android manifest so the app doesn't quit with orientation
changes, and made testgles.c exit properly on Android.
This bumps the build SDK level to 12 (up from 10). Runtime requirements remain
the same (at API level < 12 joystick support is disabled).
Also enables building SDL for armv7 and x86.
A port of the ANGLE library (OpenGL ES 2.0 for Direct3D) to WinRT, via https://github.com/stammen/angleproject, is used as a base.
To enable, clone 'angleproject' into the directory one above where SDL/WinRT is, open the file SDL/include/SDL_config_winrt.h, and uncomment the #defines that begin with 'SDL_VIDEO_OPENGL'. From there, apps can create an OpenGL capable SDL_Window via the flag, SDL_WINDOW_OPENGL, and an OpenGL ES 2 context via SDL_GL_CreateContext. The Direct3D 11.1 renderer cannot be used alongside SDL_WINDOW_OPENGL. Only Windows 8/8.1 is supported for now. Shaders may need to be precompiled, in some (all?) cases.
norfanin
The audio_enumerateAndNameAudioDevicesNegativeTests test in testautomation_audio.c reports a failure for SDL_GetAudioDeviceName when called on a driver that has only the default device. SDL_GetNumAudioDevices reports 1, but SDL_GetAudioDeviceName does not check if the index passed by the caller is in that range in this case. For positive numbers anyway.
This can be reproduced with the dummy driver on Windows and Linux.
Mai Lavelle
I've recently tried to create multiple windows and process key events for them, and found that key events weren't being generated for most of the windows. After some investigating I've observed the following effects. All but the most recently created window experience these effects...
- a focus lost event is generated immediately after the focus gained event, even tho window still has focus
- key events report window id 0 rather than the id of the window which has focus, SDL thinks no window has focus?
- giving focus to a non SDL window and then selecting an SDL window causes events to be generated as expected, but only until focus changes again
Focus change events are queued and delayed (200 ticks) before they are dispatched. The problem occurs when a focus out and focus in event are received on the same tick. When these delayed events are dispatched they will be sent in the order determined by the window list rather than the order in which they are received.
The focus out dispatch is implemented by calling SDL_SetKeyboardFocus(NULL). This will remove focus from any window, regardless of whether it is the one originally targeted by the X11 event.
Since SDL_SetKeyboardFocus() will always dispatch a focus lost event as needed, the easiest solution is simply to only call SDL_SetKeyboardFocus(NULL) when SDL_GetKeyboardFocus() matches the target window.
