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).
This scenario can occur, for example, when the 4-finger touch sequence is used to switch spaces. the SDL window does not receive the touch up events and ends up thinking there are far more fingers on the pad than there are.
So the solution here is everytime a new "touch" appears we can through and check if there are any existing known touches by the OS and if there are none, abut SDL things there are, we simply go through and cancel the SDL touches.
Side affects.
- the "touch up" won't occur until the users sends a new touch (could be well after the actual release really did occur)
Windows Phone 8.0 either did not define, or provide access to, a 'RoamingFolder'
or 'TemporaryFolder' for apps to use. Windows 8.0 and 8.1 do, as does
Windows Phone 8.1. This change allows SDL-based Windows Phone 8.1 apps to
access these folders, via either the SDL_WinRTGetFSPathUNICODE() or
SDL_WinRTGetFSPathUTF8() functions.
SDL_GetPrefPath(), which on WinRT, is based on SDL_WinRTGetFSPathUTF8(), will
continue to return the app's 'local' folder, despite Windows 8.x
counterpart apps using the 'roaming' folder, in order to preserve compatibility
when 8.0-based Phone apps upgrade to 8.1-based Phone apps.
This patch makes sure that any SDL_MOUSEBUTTONDOWN, SDL_MOUSEBUTTONUP, and
SDL_MOUSEMOTION events, as triggered by a touch event in a WinRT app, set the
event's 'which' field to SDL_TOUCH_MOUSEID. Previously, this was getting set
to the same value as events from a real mouse, '0'.
Thanks to Diego for providing information on this bug, and to Tamas Hamor for
sending over a patch!
