|
2a6213ad
|
2014-02-24T22:49:30
|
|
Make sure we don't clip the cursor while clicking on the window title bar
|
|
|
5c5770ad
|
2014-02-14T11:39:58
|
|
Make sure we don't stay in the windows event loop forever if there are lots of events coming in quickly.
|
|
|
e34da680
|
2014-02-13T11:05:28
|
|
Fixed lost mouse button when in relative mouse warp mode and you click on the title bar, entering a modal move/resize loop.
Testing:
* Set the SDL_HINT_MOUSE_RELATIVE_MODE_WARP hint true, run testsprite2, press Ctrl-R to enter relative mode, alt tab away from the window, then click on the title bar of the window. Didn't get the mouse button release before, and we do now.
CR: Yahn + Alfred
|
|
|
58edac3e
|
2014-02-02T00:53:27
|
|
Fixed bug 2374 - Update copyright for 2014...
Is it that time already??
|
|
|
dbd4a917
|
2014-01-30T12:27:24
|
|
Document Michael's changes adding TranslateMessage() back to the SDL message loop.
|
|
|
5c58bd68
|
2014-01-30T12:27:00
|
|
* Added TranslateMessage call to SDL default message pump - was causing problems in S2 tools mode apps that used Qt. Qt relies on the WM_CHAR message generated by TranslateMessage and keyboard input was showing up in the UI as mixed-case. (Depending on which message pump got a given message - both SDL and Qt pump messages for the entire process.) Sam will review and possibly tweak this change before propagating to public SDL, but I'm checking this version in so I can integrate into S2 and fix the issue there.
|
|
|
6f6c76a6
|
2013-12-27T10:18:18
|
|
Make sure our window has mouse focus before processing raw input events.
This happens rarely, but not reproducibly, where we get raw input events for the window even though it doesn't have focus.
|
|
|
2521e497
|
2013-12-23T17:55:06
|
|
Setting the mouse in relative mode implies grabbing the mouse.
This fixes getting mouse button events in raw input relative mode on X11.
|
|
|
7aef2350
|
2013-12-23T17:37:22
|
|
Added a relative mouse mode that uses mouse warping instead of raw input.
To enable this, set the environment variable SDL_MOUSE_RELATIVE_MODE_WARP to "1"
When mouse relative mode is disabled, put the cursor back where the application expects it to be, instead of where it was when relative mode was enabled.
|
|
|
7afb7682
|
2013-12-05T09:29:04
|
|
Added code missed in the resolve
|
|
f848adff
|
2013-11-29T10:06:08
|
|
Improve Android pause/resume behavior.
|
|
|
d2511d9e
|
2013-11-27T10:29:38
|
|
Fixed bug 2260 - SDL_SetCursorGrab() is buggy on Windows
BurnSpamAddress
Steps to reproduce:
1. Grab the cursor with SDL_SetCursorGrab()
2. Alt-tab away from the window
3. Click on the titlebar of the window
This will cause the window to disappear underneath the taskbar!
This appears to be a general issue with ClipCursor() on windows, i.e. I am getting the same behavior if I call ClipCursor() directly.
It is caused by a feedback loop between the ClipCursor function and the modal resize/move event loop that handles mouse-based sizing on Windows.
|
|
|
fa4e4a64
|
2013-11-27T10:29:32
|
|
Fixed large relative mouse motion when iconifying the SDL window.
Windows will move the window to -32000,-32000 when it is iconified, so we don't want to send mouse motion for iconic windows.
|
|
|
2bb344d6
|
2013-11-27T10:29:27
|
|
Don't crash when no WM is present.
CR: Sam Lantinga.
|
|
7e1289af
|
2013-11-24T23:56:17
|
|
Make internal SDL sources include SDL_internal.h instead of SDL_config.h
The new header will include SDL_config.h, but allows for other global stuff.
|
|
|
5b8b403e
|
2013-11-13T11:18:37
|
|
[Windows] Fixes bug #1555, handle ALT+F4 on Windows
|
|
|
e19f15dd
|
2013-11-10T14:10:00
|
|
Fixed bug 2067 - Window size limit calculation issue when exiting fullscreen on Windows
Also fixed minimize and maximize state detection for Windows.
|
|
|
48e44f7f
|
2013-11-06T23:59:24
|
|
Fixed Windows compile error
|
|
|
3b050fc9
|
2013-11-06T23:35:08
|
|
Horizontal wheel support in windows
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.
|
|
|
fea2699c
|
2013-10-14T08:56:50
|
|
Fixed the windows message debug output so it works without HAVE_LIBC
|
|
|
8ec3ba38
|
2013-10-13T19:59:40
|
|
Fixed accumulating mouse wheel motion for the Microsoft Wireless Mouse 5000
|
|
|
1e49b1ed
|
2013-08-21T09:47:10
|
|
OCD fixes: Adds a space after /* (glory to regular expressions!)
|
|
|
695344d1
|
2013-08-21T09:43:09
|
|
OCD fixes: Adds a space before */
|
|
|
552b04c5
|
2013-08-20T20:34:40
|
|
More non C89 compliant comments
|
|
|
9ab14aa5
|
2013-08-16T17:50:44
|
|
Fixed windows build
|
|
|
ff77ca8d
|
2013-08-16T15:38:06
|
|
The keyboard text events should be sent after the key down events
|
|
|
b4b12d95
|
2013-08-16T15:35:10
|
|
Fixed bug 1876 - SDL_TEXTINPUT only returns '?' (0x3F) in event.text.text with Khmer language input
Andreas
The issue comes down to this line on MSDN:
"TranslateMessage produces WM_CHAR messages only for keys that are mapped to ASCII characters by the keyboard driver."
"WM_KEYDOWN and WM_KEYUP combinations produce a WM_CHAR or WM_DEADCHAR message. WM_SYSKEYDOWN and WM_SYSKEYUP combinations produce a WM_SYSCHAR or WM_SYSDEADCHAR message."
Except for WM_CHAR, none of these messages are used in SDL. Hence TranslateMessage should be dropped entirely and proper handling be included in the WM_KEYDOWN event.
Currently TranslateMessage is called for every message even if it must not be called in certain cases (like "An application should not call TranslateMessage if the TranslateAccelerator function returns a nonzero value.").
WM_CHAR message handling should remain for external processes posting these messages - additionally, WM_UNICHAR should be added.
I made a patch for src/video/windows/SDL_windowsevents.c that seems to work fine. It doesn't solve the "missing" composition for Khmer, but at least input for languages that cannot be mapped to ASCII characters (and for which IME is not used) will now work on Windows.
|
|
|
dad42067
|
2013-08-12T11:13:50
|
|
Fixes #2022, do not resume on Android when surfaceChanged
If the app is in landscape mode and the user presses the power button, a pause
is followed immediately by a surfaceChanged event because the lock screen
is shown in portrait mode. This triggers a "false" resume.
So, we just pause and resume following the onWindowFocusChanged events.
Also, wait for SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERBACKGROUND before
blocking the event pump.
|
|
|
1ad936eb
|
2013-08-11T19:56:43
|
|
Fixed bug 2027 - Full-screen appears to be broken - hang in SDL_DestroyWindow()
Rainer Deyke
I'm running Linux Mint 15 with the Cinnamon window manager. SDL_DestroyWindow consistently locks up for me when the window if fullscreen.
|