| Summary: | [OSX 10.11] SDL_SetRelativeMouseMode without SDL_HINT_MOUSE_RELATIVE_MODE_WARP does not work | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Bjorn W <bjorn+sdlbug> |
| Component: | events | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | amaranth72, ewasylishen |
| Version: | 2.0.4 | ||
| Hardware: | x86 | ||
| OS: | Other | ||
|
Description
Bjorn W
2016-04-21 12:17:22 UTC
The problem is in src/video/cocoa/SDL_cocoamouse.m in the Cocoa_HandleMouseEvent() method.
The fix is the removal of the ignore clause below (my #if 0). If we're in relative mode, I fail to see how it makes sense to check the locationInWindow at all, and indeed it fails here and this is why it doesn't work. I think you can just remove that if() completely. If we're in non-relative mode, the code is not executed there anyway.
------
/* Non-relative movement is handled in -[Cocoa_WindowListener mouseMoved:] */
if (!mouse->relative_mode) {
return;
}
#if 0
/* Ignore events that aren't inside the client area (i.e. title bar.) */
if ([event window]) {
NSRect windowRect = [[[event window] contentView] frame];
if (!NSPointInRect([event locationInWindow], windowRect)) {
return;
}
}
#endif
I can reproduce it on the latest mercurial, 6ad89111cb4f 1. open SDLTest.xcodeproj 2. select the "testrelative" target 3. click the run button 4. when the window appears, move the mouse. The red square is expected to move, but it does not. I found a workaround: Cmd+Tab to another app, then click on the title bar of the testrelative window. Bjorn, your fix works for me too. I checked the hg blame and the "Ignore events that aren't inside the client area (i.e. title bar.)" block was inserted in this commit: http://hg.libsdl.org/SDL/rev/028ed8da2524 Looks like the intent of that block of code is so Cmd+Tabbing to another app, then dragging the title bar of the SDL window doesn't generate mouse events. -- I added an NSLog, and when the return statement is hit, the mouse NSPoint is {0, 480}, and the windowRect is: {{0, 0}, {640, 480}}, so it's an off by one issue. Seems like there is a NSMouseInRect designed to deal with these cases.. maybe this is a proper fix? diff -r 6ad89111cb4f src/video/cocoa/SDL_cocoamouse.m --- a/src/video/cocoa/SDL_cocoamouse.m Mon Apr 25 22:17:38 2016 +0200 +++ b/src/video/cocoa/SDL_cocoamouse.m Sat Apr 30 19:55:43 2016 -0600 @@ -398,7 +398,7 @@ /* Ignore events that aren't inside the client area (i.e. title bar.) */ if ([event window]) { NSRect windowRect = [[[event window] contentView] frame]; - if (!NSPointInRect([event locationInWindow], windowRect)) { + if (!NSMouseInRect([event locationInWindow], windowRect, NO)) { return; } } I've pushed a commit which changes the mouse code in the Cocoa backend to use NSMouseInRect instead of NSPointInRect, thanks Eric! Let me know how it works out – it seemed to fix things in my own tests. https://hg.libsdl.org/SDL/rev/d41acf6379f6 Thanks! I tested the latest HG on both OS X 10.11.4 and 10.6.8, and testrelative is working on both versions of OS X. |