WinRT apps can set a default, preferred orientation via a .appxmanifest file.
SDL was overriding this on app startup, and making the app use all possible
orientations (landscape and portrait).
Thanks to Eric Wing for the heads up on this!
Further support regarding IME and on-screen keyboards is pending, some of
which might not be 100% compatible with other platforms, given WinRT platform
restrictions. An MSDN article at http://msdn.microsoft.com/en-us/library/windows/apps/hh465404.aspx
indicates that on-screen keyboard display requires that the user first tap on
a Windows/XAML text control.
This change adds basic SDL_TEXTINPUT support, with input coming from hardware
keyboards, at a minimum, and without the need for XAML integration (which is
still pending integration into SDL, by and large).
Philipp Wiesemann
I attached a patch for an incomplete implementation of the messagebox parts.
It was not tested on lots of devices yet and features a very fragile workaround to block the calling SDL thread while the dialog is handled on Android's UI thread. Although it works for testmessage.c I assume there are lot of situations were it may fail (standby, device rotation and other changes). Also not all flags and colors are implemented.
On the other hand most uses of the messagebox are to show an error on start and fragility (or working at all) may not matter there.
+ Handle HidePreeditText IBus signal.
+ Use SDL_GetKeyboardFocus instead of SDL_GetFocusWindow.
+ Move the X11 IBus SetFocus calls to the X11_DispatchFocus functions.
+ Simplify the IBus ifdefs when handling X11 KeyEvents.
+ Remove inotify watch when SDL_IBus_Quit is called.
Notes:
- Support for the 'Guide' button does not seem to be possible, as
XInputGetStateEx is not available on WinRT.
- Haptic support appears to be working on WinRT now!
- SDL/WinRT does not allow calls to LoadLibrary or LoadLibraryEx. The calls
to those were removed by this change, but only when compiling for WinRT.
Non-WinRT Windows will continue to detect and load XInput via LoadLibrary and
GetProcAddress calls.
SDL_WINDOWEVENT_FOCUS_LOST is now sent when an app's native window is hidden.
Likewise, SDL_WINDOWEVENT_FOCUS_GAINED is sent when an app's window is shown.
This mimicks behavior seen on iOS and Android.
SDL_WINDOWEVENT_MINIMIZED and SDL_WINDOWEVENT_RESTORED are now sent when the
app's native window is hidden and shown. Previously, these were sent when an
app was suspended and resumed. On Windows 8.x/RT, an app may be sent to the
background without being suspended, which previously meant that
SDL_WINDOWEVENT_MINIMIZED might never have been sent. (On Windows Phone 8,
however, this seems to be different, whereby apps sent to the background appear
to always get suspended.)
SDL_APP_WILLENTERBACKGROUND is now sent as soon as the app is told that it is
about to go to the background. SDL_APP_DIDENTERBACKGROUND is sent via a WinRT
'deferral operation', which is how WinRT gives apps a bit of extra time
(multiple seconds worth) to prepare for an app-backgrounding.
The distinction may be important as the deferral operation's code is always run
in a separate thread. For Direct3D-only apps, this means that between the
two SDL app-backgrounded events, SDL_APP_WILLENTERBACKGROUND will be the only
one run from the main thread. Given that some WinRT operations can only be done
on the main thread (operations to the CoreWindow fall into this category), this
could be important.
It is important to note that pre-deferral code may only have a very short bit of
time to execute code, less so than code run in the deferral operation (where
SDL_APP_DIDENTERBACKGROUND is sent from), which usually gets several seconds to
run.
Rotation detection and handling should now work across all, publicly-released,
WinRT-based platforms (Windows 8.0, Windows 8.1, and Windows Phone 8.0).
