Sylvain
Hi! here's a patch for that with two class loaded regarding API level.
Test both case : before API 11 and after.
I also remove now unused GetSystemServiceFromUIThread() and minor clean-up (haptic warning prototype).
Sylvain
Small patch for this issue. I tested it and it seems to work.
- it can send several backspaces (instead of only 1).
- it calls directly "sendKeyEvent()" instead of "super.sendKeyEvent()".
otherwise, it would go through the android internals, calling again "onKey()".
and then the "backspace" would arrive after the next "commitText()".
sfalexrog
Android haptic code was not added to CMakeLists.txt, leading to build failures when targeting Android platform.
Attached patch adds Android haptic driver to source sets and adds configuration parameter to SDL_config.h.cmake.
Tom Seddon
0f0ad62237 (git head at the time of writing); Visual Studio 2015, toolset v140, Platform 10.0.14393.0, building for x64
Windows non-MinGW cmake build sets defines implying wcslcpy and wcslcat are available, but Windows doesn't have these functions.
Ryan C. Gordon
That's weird, these are the exact two functions that Emscripten incorrectly believed it had until we upgraded the buildbot's emsdk install.
Not sure what's up with this, but it's possibly not a MingW-specific thing!
This fixes a strange corner case (notes appended below), and should be
safe to do anyhow.
Fixes Bugzilla #3674.
"I did more tests.
It appears the bug only happens if there is
another window on the screen that has "always
on top" property. For me it is xawtv - it is
always opened in a screen corner. Closing
xawtv or removing "always on top" property
from it makes the problem to go away.
Plus, it doesn't appear like the buttons are
not delivered at all. It appears that instead
the button presses are delivered on some mouse
positions, but not delivered when you move the
mouse to other part of the window... So this is
really weird and is likely somewhere deep in the
Xorg.
Maybe somehow it happens that the cursor is
actually above the xawtv window, but, because
my app uses grab, it is not visible there, and
in that case the events are not delivered to
my app?
But with my patch the button events are
always delivered flawlessly, it seems.
Hmm, and that indeed seems to explain my problem:
if the mask is set properly and my app uses
grab, then, even if the mouse is above some
other window, the events would still be delivered
to the grabbing app, which is what actually wanted
because my app uses relative mouse mode, so it
doesn't know the pointer can cross some other window
(my app draws the pointer itself).
So my current theory is that my patch only enforces
the mouse grab, which otherwise can be tricked by
some other window preventing the button events
delivery (but motion events are still delivered
via xinput2, which makes it all look very obscure)."
This patch was originally written by Marc Di Luzio for glX and enhanced by
Maximilian Malek for WGL, etc. Thanks to both of you!
Fixes Bugzilla #3643.
Fixes Bugzilla #3735.
--HG--
extra : rebase_source : 4339a25375897f157f59719876086f84acc10aad
macOS currently needs this if you build with X11 support. iOS doesn't
(currently), but it doesn't hurt to compile it in case we do something
Unixy on that platform later on.
