Todd Seiler
Call Stack:
#0 0x0000000101c29291 in Cocoa_StartTextInput at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoakeyboard.m:512
#1 0x0000000101c110c5 in SDL_SetKeyboardFocus at /Users/Todd/Desktop/codes/sources/SDL/src/events/SDL_keyboard.c:643
#2 0x0000000101c32be4 in SetupWindowData at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoawindow.m:981
#3 0x0000000101c32d2a in Cocoa_CreateWindowFrom at /Users/Todd/Desktop/codes/sources/SDL/src/video/cocoa/SDL_cocoawindow.m:1092
#4 0x0000000101c99999 in SDL_CreateWindowFrom_REAL at /Users/Todd/Desktop/codes/sources/SDL/src/video/SDL_video.c:1338
#5 0x0000000101ce1484 in SDL_CreateWindowFrom at /Users/Todd/Desktop/codes/sources/SDL/src/dynapi/SDL_dynapi_procs.h:547
#6 0x0000000100018a5e in SceneRenderer at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/SceneRenderer.cpp:138
#7 0x0000000100017ca5 in SceneRenderer at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/SceneRenderer.cpp:145
#8 0x000000010000cd96 in App::execute(int, char**) at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/App.cpp:28
#9 0x0000000100004402 in main at /Users/Todd/Desktop/codes/sources/tseiler_Todds-MacBook-Pro_3405/AppName/src/main.cpp:8
This issue occurred when using Ogre3D Graphics engine on Mac (cocoa) to create the window. Then handing the window handle off to SDL_CreateWindowFrom().
In Ogre3D application you do the following:
window_ = root_->initialise(true, "Ogre Window 2");
loadOgreResources();
Ogre::WindowEventUtilities::addWindowEventListener(window_, this);
#if OGRE_PLATFORM == OGRE_PLATFORM_APPLE
NSWindow* Data = 0;
window_->getCustomAttribute("WINDOW", &Data);
sdl_window_ = SDL_CreateWindowFrom((void*)Data);
#endif
It results in a crash in this function:
SDL_cocoakeyboard.m
void
Cocoa_StartTextInput(_THIS)
{
SDL_VideoData *data = (SDL_VideoData *) _this->driverdata;
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
SDL_Window *window = SDL_GetKeyboardFocus();
NSWindow *nswindow = nil;
if (window)
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow;
// ...
}
The crash occurred because "driverdata" was nil. Before this function call, a call to SetupWindowData is called:
SDL_cocoawindow.m
static int
SetupWindowData(_THIS, SDL_Window * window, NSWindow *nswindow, SDL_bool created)
{
// ...
if ([nswindow isKeyWindow]) {
window->flags |= SDL_WINDOW_INPUT_FOCUS;
SDL_SetKeyboardFocus(data->window);
}
/* Prevents the window's "window device" from being destroyed when it is
* hidden. See http://www.mikeash.com/pyblog/nsopenglcontext-and-one-shot.html
*/
[nswindow setOneShot:NO];
/* All done! */
[pool release];
window->driverdata = data;
return 0;
}
As you can see: "window->driverdata = data" is performed after the "SDL_SetKeyboardFocus()" call, which eventually leads to "Cocoa_StartTextInput()" where the crash occurs.
Testing:
* For each theme in Windows 7, Windows 7 Basic, and Windows 7 Classic:
- Ran testsprite2
- Pressed Ctrl-G to grab the mouse
- Alt-tabbed away, verified mouse is no longer grabbed
- Alt-tabbed back, verified that mouse was grabbed
- Alt-tabbed away
- Clicked in the window, verified mouse was grabbed
- Alt-tabbed away
- Grabbed the title bar and dragged the window around successfully, verified that mouse was grabbed when move modal loop completed
- Alt-tabbed away
- Clicked the minimize button on the title bar, the window was successfully minimized
- Clicked on the icon in the task bar, the window was restored and the mouse grabbed again
- Alt-tabbed away
- Clicked the close button on the title bar, the window was successfully closed
callow.mark
Compiling with SDL_VIDEO_RENDER_OGL=0, SDL_VIDEO_OPENGL=0, SDL_VIDEO_OPENGL_WGL=0, SDL_VIDEO_RENDER_OGL_ES2=1, SDL_VIDEO_OPENGL_ES2=1 and SDL_VIDEO_OPENGL_EGL=1 set in SDL_config_windows.h fails.
A patch is attached. See bug #2570 for reasons you might want to compile this way.
Alex Szpakowski
Now that SDL for iOS requires at least iOS 5.1 at runtime, there are several old codepaths in the UIKit backend which can be removed. I've attached a patch which does so.
Melker Narikka
Local files that are dropped onto a window under X11
are not going through a URI decoding step, resulting in the following
in my test application:
Dropped file /home/meklu/Pictures/Screenshot%20from%202013-10-30%2014:04:50.png
Couldn't load /home/meklu/Pictures/Screenshot%20from%202013-10-30%2014:04:50.png
Expected result:
Dropped file /home/meklu/Pictures/Screenshot from 2013-10-30 14:04:50.png
Loaded /home/meklu/Pictures/Screenshot from 2013-10-30 14:04:50.png successfully
I've attached a patch that fixes the issue by doing URI decoding in-place on
the file string buffer.
Diego
The Xcode Instruments Leak tool reports a leak from IODisplayCreateInfoDictionary in Cocoa_GetDisplayName.
This happened after upgrading to Xcode 5.
This makes the X error handler used for GL context creation handle *all* errors
and provide the user with specific error messages when SDL_GL_CreateContext
fails.
CR: icculus@icculus.org
Alex Szpakowski
Patch to fix the y component of the position of fullscreen windows in OS X.
In Mac OS X with the latest Mercurial code, when a window is in exclusive-fullscreen the y component of its position is offset by the same amount that is normally taken up by the menubar, resulting in a black bar at the top of the screen.
The recent changes to the internal ConvertNSRect function make it treat the bottom of the menubar as 0 for the y component of window positions, even when the window is fullscreen and 'above' the menubar.
I have attached a patch which fixes the issue by only making the window position relative to the menubar in windowed modes.
Eric Wasylishen
Steps to reproduce:
- Run testwm2 app in the SDLTest Xcode project
- Press Control+R to enable relative mouse mode. The mouse cursor should disappear.
- Press Control+Enter to enter fullscreen.
- Expected: a black screen with no cursor visible. Observed: a black screen, but the mouse cursor is visible in the middle of the screen. It doesn't move when I move the mouse.
Reproduced with latest sdl2 hg (changeset f6010ead184f) on OS X 10.9.2. Can't reproduce the problem on OS X 10.6.8 or 10.7.5.
I'm speculating that this really an Apple bug.. but anyway, the attached workaround seems to fix it for me, and I think it's fairly safe.
A more obvious idea, sticking a call SDL_SetCursor(NULL) at the end of Cocoa_SetWindowFullscreen, didn't work.
Eric Wasylishen
The problem seems to be the spaces handling code in -setFullscreenSpace: (SDL_cocoawindow.m) is incorrectly reporting that the SDL_WINDOW_FULLSCREEN -> windowed transition has already happened.
i.e. I saw this case was getting hit when trying to leave SDL_WINDOW_FULLSCREEN:
"else if (state == isFullscreenSpace) {
return YES; /* already there. */
}"
With the attached patch, both Control+Enter (SDL_WINDOW_FULLSCREEN toggle) and Option+Enter (SDL_WINDOW_FULLSCREEN_DESKTOP toggle) work in an sdl test app (I tried testwm2). Tested on OS X 10.9.2.
snake5creator
When starting application with the usual "double click on file" method on Windows, only holding the last click, an unnecessary MOUSEBUTTONDOWN event is sent before the initial MOUSEMOTION event, and mouse button state is stuck in the sense that it takes a subsequent button release, followed by another press for the system to resume sending events (beginning with the next button release / MOUSEBUTTONUP event).
Input event log with held double-click startup: http://i.imgur.com/nypGKR2.png
Without: http://i.imgur.com/yaIqAvV.png
