src/video/cocoa/SDL_cocoawindow.m


Log

Author Commit Date CI Message
Ozkan Sezer 19aaa294 2020-10-09T04:00:00 Fix https://bugzilla.libsdl.org/show_bug.cgi?id=5306 (Also see: https://bugzilla.libsdl.org/show_bug.cgi?id=4822) Building the current tree against 10.8 SDK, clang emits the following warning: src/video/cocoa/SDL_cocoawindow.m:1846:27: warning: instance method '-isOperatingSystemAtLeastVersion:' not found (return type defaults to 'id') [-Wobjc-method-access] ![processInfo isOperatingSystemAtLeastVersion:version]) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/MacOSX10.8.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSProcessInfo.h:20:12: note: receiver is instance of class declared here @interface NSProcessInfo : NSObject { ^ 1 warning generated. isOperatingSystemAtLeastVersion is an 10.10 thing.
Sam Lantinga 97ca96bd 2020-05-27T10:13:01 Use nil instead of NULL for Objective-C objects
Sam Lantinga af5eb56c 2020-05-27T09:28:03 Fixed uninitialized variable warning
Cameron Gutman 77b0dad2 2020-05-25T20:55:29 cocoa: Change Caps Lock behavior to toggle instead of locking It currently behaves like a locking key which is pressed when Caps Lock is enabled and released when disabled. This means that apps that trigger events on Caps Lock key down will only fire these events every other time Caps Lock is pressed.
Sam Lantinga b47f577a 2020-05-11T14:36:23 Fixed bug 5098 - macOS CreateWindowFrom doesn't work with high-dpi displays michaeljosephmaltese Display ends up taking only 1/4 of the screen area. It needs to call "setWantsBestResolutionOpenGLSurface:highdpi", like when creating a window the normal way.
Ryan C. Gordon 6e6b5177 2020-04-07T23:34:41 cocoa: Patched to compile.
Michael Maltese 361417c0 2020-03-25T16:40:43 cocoa: allow calling CreateWindowFrom on an NSView This lets applications embed SDL with other widgets surrounding it. Already possible on Windows and X11. Fixes Bugzilla #5060.
Sam Lantinga 1fd548b6 2020-03-23T11:42:44 Fixed building back to Mac OSX using the 10.7 SDK
Sam Lantinga 51e9e984 2020-03-01T13:00:50 Fixed whitespace
Sam Lantinga 8a6f1aa5 2020-03-01T12:58:50 Fixed bug 4369 - Going fullscreen with green knob in MacOS freezes app for 15 seconds. Elmar creating a fullscreen window with SDL_CreateWindow(..SDL_WINDOW_FULLSCREEN_DESKTOP..) in MacOS works fine, except if it was triggered by the user with the green knob in the top left window title bar. Then "something" is different, and SDL_CreateWindow hangs for 15-20 seconds (tested in MacOS 10.13 and 10.14). Responsible for the hang is this code in SDL_cocoawindow.m - Cocoa_SetWindowFullscreenSpace: const int maxattempts = 3; int attempt = 0; while (++attempt <= maxattempts) { /* Wait for the transition to complete, so application changes take effect properly (e.g. setting the window size, etc.) */ const int limit = 10000; int count = 0; while ([data->listener isInFullscreenSpaceTransition]) { if ( ++count == limit ) { /* Uh oh, transition isn't completing. Should we assert? */ break; } SDL_Delay(1); SDL_PumpEvents(); } if ([data->listener isInFullscreenSpace] == (state ? YES : NO)) break; /* Try again, the last attempt was interrupted by user gestures */ if (![data->listener setFullscreenSpace:(state ? YES : NO)]) break; /* ??? */ } One trivial workaround is to change 'const int limit = 10000' to 500. Then the freeze is so short that it doesn't look like a freeze to the user. Looking further into the problem, I observed that the function Cocoa_SetWindowFullscreenSpace recursively calls itself via some ObjectiveC messages. I managed to extract a callstack for this (copied below): Note how Cocoa_SetWindowFullscreenSpace in stack line 22 calls SDL_PumpEvents, which eventually arrives at SDL_SendWindowEvent, which calls SDL_UpdateFullscreenMode (stack line 0), which then calls Cocoa_SetWindowFullscreenSpace again (not shown). This recursive second call is the one that hangs. Another "solution" that worked for me was to add a flag to SDL_Window that is set in Cocoa_SetWindowFullscreenSpace and causes this function to return immediately if called from itself. Obviously, this is also an ugly hack, but I don't have enough time to dive into this crazy Cocoa/ObjectiveC business deep enough to find a proper solution. But hopefully it's easy for one of the experts around. Note that there is a "failure to go fullscreen"-message involved, maybe using the green knob causes this failure at first. I can unfortunately not provide a minimum example. Best regards, Elmar 0 com.yasara.View 0x00000001007495af SDL_UpdateFullscreenMode + 207 1 com.yasara.View 0x00000001006e2591 SDL_SendWindowEvent + 401 2 com.yasara.View 0x0000000100775a72 -[Cocoa_WindowListener windowDidResize:] + 370 3 com.yasara.View 0x0000000100776550 -[Cocoa_WindowListener windowDidExitFullScreen:] + 512 4 com.apple.AppKit 0x00007fff3180a2a4 -[_NSWindowEnterFullScreenTransitionController failedToEnterFullScreen] + 692 5 com.apple.AppKit 0x00007fff31c59737 -[_NSEnterFullScreenTransitionController _doFailedToEnterFullScreen] + 349 6 com.apple.AppKit 0x00007fff3172aa53 __NSFullScreenDockConnectionSendEnterForSpace_block_invoke + 135 7 libxpc.dylib 0x00007fff6114b9b1 _xpc_connection_reply_callout + 36 8 libxpc.dylib 0x00007fff6114b938 _xpc_connection_call_reply_async + 82 9 libdispatch.dylib 0x00007fff60ec7e39 _dispatch_client_callout3 + 8 10 libdispatch.dylib 0x00007fff60ede3b0 _dispatch_mach_msg_async_reply_invoke + 322 11 libdispatch.dylib 0x00007fff60ed2e25 _dispatch_main_queue_callback_4CF + 807 12 com.apple.CoreFoundation 0x00007fff33d39e8b __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 13 com.apple.CoreFoundation 0x00007fff33d3959a __CFRunLoopRun + 2335 14 com.apple.CoreFoundation 0x00007fff33d38a28 CFRunLoopRunSpecific + 463 15 com.apple.HIToolbox 0x00007fff32fd1b35 RunCurrentEventLoopInMode + 293 16 com.apple.HIToolbox 0x00007fff32fd1774 ReceiveNextEventCommon + 371 17 com.apple.HIToolbox 0x00007fff32fd15e8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 18 com.apple.AppKit 0x00007fff3128deb7 _DPSNextEvent + 997 19 com.apple.AppKit 0x00007fff3128cc56 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362 20 com.yasara.View 0x000000010076fab2 Cocoa_PumpEvents + 290 21 com.yasara.View 0x00000001006dd1c7 SDL_PumpEvents_REAL + 23 22 com.yasara.View 0x00000001007795cf Cocoa_SetWindowFullscreenSpace + 223 23 com.yasara.View 0x000000010074970b SDL_UpdateFullscreenMode + 555 24 com.yasara.View 0x00000001006e2476 SDL_SendWindowEvent + 118 25 com.yasara.View 0x0000000100774ff7 -[Cocoa_WindowListener resumeVisibleObservation] + 135 26 com.yasara.View 0x000000010077664c Cocoa_ShowWindow + 188 27 com.yasara.View 0x0000000100749492 SDL_FinishWindowCreation + 546 28 com.yasara.View 0x0000000100748da5 SDL_CreateWindow_REAL + 1573 29 com.yasara.View 0x000000010010d9b1 vga_setvideomode + 1347 30 com.yasara.View 0x00000001003f0d46 mod_initscreen + 2614 31 com.yasara.View 0x00000001003f344b mod_reinitscreen + 460 32 com.yasara.View 0x00000001003f370d mod_resizescreen + 383 33 com.yasara.View 0x0000000100418e39 mod_main + 815 34 com.yasara.View 0x000000010029ca5d main2 + 5766 35 com.yasara.View 0x000000010011d1b7 main.main_cpuok + 19
Ryan C. Gordon 094655cf 2020-02-23T14:49:03 cocoa: Make sure wait for button enable can't be infinite.
Ryan C. Gordon 72316518 2020-02-23T14:48:48 cocoa: Removed a debug printf that was accidentally committed.
Ryan C. Gordon 4d9e6e5f 2020-02-21T14:50:09 cocoa: When exiting a fullscreen space, wait for window state to normalize. A good metric of this is when the titlebar's "minimize" button is reenabled, which doesn't happen by the time windowDidExitFullscreen triggers. This fixes minimizing a fullscreen window on macOS. Fixes Bugzilla #4177.
Sam Lantinga fe8ce66b 2020-02-11T10:35:14 Attempt to make version detection safe for Mac OS X < 10.10
Sam Lantinga 52b410ab 2020-02-11T10:21:31 Workaround for bug 4822 - Broken visual output in full screen mode with OS X 10.15 sjordan We did some investigations into a different direction which I would like to share. As mentioned previously the scaling setting in the preferences play an important role for our problem and they also hint towards an issue with point/pixel scaling factors. We found an interesting correlation between our fail case and the behavior of [nsWindow.screen backingScaleFactor]. It turns out that whenever we encounter the fail case the scale factor is zero when we print it quickly after calling SDL_CreateWindow. After some time the value changes to a non-zero value. In the success case the scaling factor is nonzero 'immediately'. Note that we don't use that factor. We also find that the window backingScaleFactor does not show the strange behavior even in the fail case. We have also attempted to find out whether any event triggers the transition from zero to non-zero. We found the transition happening when we call SDL_PollEvent. We can even force this to happen by explicitly adding a SDL_PollEvent at an early stage, but it will only happen if a certain amount of time elapsed, so we need to add some sleep before the call to trigger the transition at an earlier stage. All that seems to imply that the transition happens async and that SDL_PollEvent merely causes the system to update its internal state at that time. We have also verified that the scaling setting in the preferences does NOT directly correlate to the scaling factor behavior. We find that a particular scaling setting can lead to a fail case for one resolution and a success case for another resolution. This shows that the scaling setting alone does not determine whether the problem will appear or not. We have also verified on another Mac with 10.14 that the scaling factor is always non-zero and we always have the success case. I have no idea how to interpret this initial-zero behavior and haven't found any usable information on the screen backing scale factor. It seems as 10.15 does some stuff more async than before and maybe the problem could be caused by unfortunate timings. I would be very interested to hear your opinion about that. ... Finally we found the cause of all our problems: it's the origin hack in Cocoa_SetWindowFullscreen: /* Hack to fix origin on Mac OS X 10.4 */ NSRect screenRect = [[nswindow screen] frame]; if (screenRect.size.height >= 1.0f) { rect.origin.y += (screenRect.size.height - rect.size.height); } If we comment this one out our game and testdraw2 do behave correctly. It turns out that if a window is not fully contained in the screen, it's screen property becomes zero and therefore we saw a zero when printing the backing scale factor (although it's not clear why it became nonzero later). We suggest to add a runtime check which skips this code for 10.15 (or possibly earlier if you happen to know that the hack is not needed for certain older versions). More info: consider the line NSRect screenRect = [[nswindow screen] frame]; in Cocoa_SetWindowFullscreen. We found that this rect has the dimensions of the desktop on our OS X 10.15 setup. This is true both for the success case and the fail case. It seems as the success case is actually a fail case in disguise. On the other Mac with OS X 10.14 the same rect has the dimension of the newly created screen. This is what I would expect, because at that time the window has already been created successfully and there should be a newly created screen associated to the window. What are the cases in which the whole origin conversion code for the fullscreen case is supposed to have a non-trivial result? Today we found that if we print the dimensions of [nswindow screen] later, then we find them to be correct. So the conclusion seems to be that OS X 10.15 does indeed do the window/screen setup more async than before and that the origin correction code uses the [nswindow screen] at a time where the window/screen setup isn't finalized yet.
Sam Lantinga a8780c6a 2020-01-16T20:49:25 Updated copyright date for 2020
Ryan C. Gordon d5e378d1 2019-10-15T00:59:10 cocoa: Implement SDL_WINDOW_ALWAYS_ON_TOP support (thanks, Gabriel!). Fixes Bugzilla #4809.
Alex Szpakowski 074f6a51 2019-10-14T00:51:53 macOS: Fix the initial window background not being black since macOS 10.14.2 or so, when OpenGL is used (bug #4810). Also fixes "CGContext: invalid context 0x0" errors when an OpenGL window is created (bug #4470).
Alex Szpakowski 009226c6 2019-10-13T21:39:20 macOS: Fix non-highdpi OpenGL contexts not scaling properly in macOS 10.15 (bug 4810 and 4822).
Alex Szpakowski 1773da89 2019-10-13T12:16:40 macOS: Fix a new issue in 10.15 where the window decorations don't always get restored after SDL_SetWindowFullscreen(window, 0).
Alex Szpakowski f3683d3a 2019-08-04T23:30:55 macOS: fix a typo in touch handling code.
Alex Szpakowski d5ec735a 2019-08-01T18:22:12 Add a windowID field to SDL_TouchFingerEvent (bug #4331). This is unimplemented on some platforms and will cause compile errors when building those platform backends for now.
Alex Szpakowski 8fb8adfc 2019-07-13T17:04:02 macOS: Fix SDL_GL_CreateContext/MakeCurrent on non-main threads causing a Main Thread Checker warning when built with Xcode 11 / the macOS 10.15 SDK. Fixes bug #4714.
Ryan C. Gordon 27ad8e5d 2019-07-11T01:07:14 cocoa: Set keyboard mod state correctly when turning off capslock. Fixes Bugzilla #4716.
Ryan C. Gordon e841b066 2019-07-08T13:41:01 cocoa: Another attempt at mouse vs touch support. This time, we make anything we think is a MacBook trackpad report its touches as SDL_MOUSE_TOUCHID, even though they're not _actually_ synthesized events, and let all mouse input--even if the OS synthesized it from a multitouch trackpad on our behalf--look like physical input. This is backwards from reality, but produces the results most apps will expect. Note that if you have a real touch device that doesn't appear to be the trackpad, it'll produce real touch events with unique device ids, so it's not a total loss here, but also note that the way we decide if it was the trackpad is an imperfect heuristic; it happens to work out right now, but it's not impossible that a real touchscreen could come to the Mac at some point and (incorrectly?) call it a "mouse" input, etc. But for now, good enough. Fixes Bugzilla #4690.
Ryan C. Gordon d2d06f44 2019-07-02T12:29:36 cocoa: Don't report trackpad mouse events as synthesized touches. Fixes Bugzilla #4690, sort of. I guess.
Ryan C. Gordon 57e08c27 2019-06-26T13:21:43 cocoa: Check for capslock in -[NSResponder flagsChanged], not with IOKit. Using IOKit for this pops up a warning at startup on macOS 10.15 ("Catalina"), asking the user to authorize the app to listen to all keyboard input in the system, which is unacceptable. I _think_ we were using IOKit under incorrect presumptions here; the Stack Overflow link mentioned in it was complaining about not being able to use flagsChanged to differentiate between left and right mod keys, but that's not an issue for capslock. It's also possible this code was trying to deal with capslock changing when the window didn't have focus, but we handle this elsewhere now, if we didn't at the time.
Ryan C. Gordon ed8b78d3 2019-06-14T21:18:53 cocoa: ignore compiler warnings about OpenGL being deprecated.
Ryan C. Gordon 90e2dc98 2019-06-14T18:23:51 A few minor changes to placate static analysis.
Ryan C. Gordon d9a2eff2 2019-06-13T21:31:03 cocoa: Another attempt at synthesized mouse/touch events.
Ryan C. Gordon 29457464 2019-06-13T01:57:13 cocoa: Revised synthesized mouse/touch event strategy. I _think_ I understand what Sylvain is working on here now, so hopefully I got this right. Fixes Bugzilla #4576. (I think!)
Ryan C. Gordon 781692c0 2019-06-09T19:27:25 cocoa: report proper input IDs for mouse/touch events. Otherwise, we generate incorrect mouse events for MacBook trackpads (which are also multitouch devices), etc. Partially fixes Bugzilla #4576.
Cameron Gutman 9b220282 2019-04-28T17:37:49 Fix use-after-free when pumping the event loop after SDL_DestroyWindow() Closing the window is asynchronous, but we free the window data immediately, so we can get an updateLayer callback before the window is really destroyed which will cause us to access the freed memory. Clearing the content view will cause it to be immediately released, so no further updateLayer callbacks will occur.
Sam Lantinga 5e13087b 2019-01-04T22:01:14 Updated copyright for 2019
Sam Lantinga bd08d72d 2018-12-11T20:04:10 Fixed building with the 10.10 SDK
Sam Lantinga 1c9595b1 2018-12-08T11:06:40 Fixed bug 4415 - SDL menu bar is nonstandard on Mac foo.null I'm on macOS 10.14 and I think I'm using or around SDL 2.0.9. This is about the menu bar that SDL sets up which looks like: <App Name> <Window> <View> 1. View menu never proceeds after the Window menu in any Mac application (it is always before). 2. For SDL, the only purpose of the View menu is for a single fullscreen menu item, which is not justifiable enough to reserve space for a menu. The View menu should thus be removed, and the full screen menu item should be added at the end inside of Window's menu. See built in apps like Dictionary, Chess, App Store (on 10.14) that do this. 3. SDL should add a "Close" menu item to the Window's submenu, and it should be the first item. Its key equivalent should map to command w. Without this, you cannot close the game window via this shortcut, and you cannot close the app's About window via this shortcut. 4. Apps typically use "Enter Full Screen" or "Exit Full Screen" depending on context, not "Toggle Full Screen" which is less user friendly -- I personally care about this point the least.
Sam Lantinga 5c5ba0e3 2018-11-19T21:35:59 Fixed bug 4394 - Crash in SDL_PumpEvents() after SDL_DestroyWindow() Cameron Gutman After updating to SDL 2.0.9, I got a user report that my app was crashing when closing a SDL_WINDOW_FULLSCREEN window to return to my Qt-based UI. It looks like the dead SDL window is getting a spurious updateLayer call which is causing SDL to dereference a null SDL_WindowData pointer. For some reason, this only happens when using SDL_WINDOW_FULLSCREEN and not windowed or SDL_WINDOW_FULLSCREEN_DESKTOP. I was also unsuccessful in my attempt to get a simple reproducer for this crash. The Session.cpp code is available https://github.com/moonlight-stream/moonlight-qt/blob/688c4a90d994aa23e7b0af3ffcbb8707886db780/app/streaming/session.cpp but I slightly modified it (adding a SDL_PumpEvents() call at 1179 to immediately trigger the issue, otherwise it happened when Qt next pumped the event loop). The crashing line is: NSMutableArray *contexts = data->nscontexts;
Alex Szpakowski c525ff35 2018-11-10T20:56:23 cocoa: fix building with the macOS 10.7 SDK (thanks Riccardo!) Fixes bug #4368
Alex Szpakowski 5029d50e 2018-11-10T16:15:48 Add SDL_TouchDeviceType enum and SDL_GetTouchDeviceType(SDL_TouchID id). Touch device types include SDL_TOUCH_DEVICE_DIRECT (a touch screen with window-relative coordinates for touches), SDL_TOUCH_DEVICE_INDIRECT_ABSOLUTE (a trackpad-style device with absolute device coordinates), and SDL_TOUCH_DEVICE_INDIRECT_RELATIVE (a trackpad-style device with screen cursor-relative coordinates). Phone screens are an example of a direct device type. Mac trackpads are the indirect-absolute touch device type. The Apple TV remote is an indirect-relative touch device type.
Ryan C. Gordon cad0a2f7 2018-10-18T12:05:05 cocoa: Fix OpenGL rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272. (transplanted from 54729119b348e8a4a916192d1d6cb8d115656255)
Ryan C. Gordon f6773773 2018-10-18T12:05:05 cocoa: Fix OpenGL rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272.
Ryan C. Gordon 7689162c 2018-09-26T20:10:32 cocoa: Force an OpenGL context update when the window becomes key. Fixes missing rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272.
Ryan C. Gordon 22475bf3 2018-09-26T20:10:32 cocoa: Force an OpenGL context update when the window becomes key. Fixes missing rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272. (transplanted from aee4797c84ef90464e270b1f6095a6dd7ce280c1)
Sam Lantinga 5febdfce 2018-09-24T11:49:25 Fixed whitespace
Ryan C. Gordon e061a92d 2018-08-02T16:03:47 Some drag'and'drop improvements. First: disable d'n'd events by default; most apps don't need these at all, and if an app doesn't explicitly handle these, each drop on the window will cause a memory leak if the events are enabled. This follows the guidelines we have for SDL_TEXTINPUT events already. Second: when events are enabled or disabled, signal the video layer, as it might be able to inform the OS, causing UI changes or optimizations (for example, dropping a file icon on a Cocoa app that isn't accepting drops will cause macOS to show a rejection animation instead of the drop operation just vanishing into the ether, X11 might show a different cursor when dragging onto an accepting window, etc). Third: fill in the drop event details in the test library and enable the events in testwm.c for making sure this all works as expected.
Sam Lantinga e3cc5b2c 2018-01-03T10:03:25 Updated copyright for 2018
Sam Lantinga 57ebc727 2017-12-04T20:35:01 Fixed bug 3975 - Add GLES2 support for macOS via ANGLE library Andrey Seems latest google angle library successfully built & tested under macOS'es. https://github.com/google/angle We need to use GLES2 to implement true cross-platform code.
Ryan C. Gordon 9bbf92e3 2017-10-25T18:02:11 cocoa: Don't change the NSWindow background color. Changing the background color causes the titlebar to blend against it on modern macOS releases, making all SDL windows look wrong by default. This was set to make the window not flash white before a GL context is ready, but we can accomplish this in our window's view's drawRect implementation, too.
Sam Lantinga b2ba8963 2017-09-09T11:00:25 Fixed bug 3809 - Restore after maximize leads to wrong size Andreas Falkenhahn My app opens a 640x480 window. When I click on the window's maximize button, the window correctly fills the entire screen and loses its borders. But clicking on the restore button now doesn't restore the window to its original 640x480 size. Instead, the window size is identical to the screen size now. The only difference to the previous state is that the window now has borders again but it isn't restored to 640x480.
Sam Lantinga 676c3a92 2017-09-09T10:31:44 Fixed bug 3719 - Cocoa - Incorrect window size when leaving fullscreen bastien.bouclet The window is now resized to its specified size, but it moves to the top left corner of the screen. That is unexpected because neither the user nor the program moved it there. Test program attached (the same one as before).
David Ludwig 532446a6 2017-09-03T17:33:49 macOS: bug-fix for #3793, "fullscreen toggle does not maintain SDL_Renderer's logical size" This also seems to fix the follow-up issue in bug #3719, whereby the initial fix caused the SDL window to move, after transitioning from fullscreen to windowed-mode
Alex Szpakowski d7ae3131 2017-08-31T21:34:29 macOS: Fix menubar items being enabled when they shouldn't be.
Alex Szpakowski cfd7a7fa 2017-08-31T21:13:32 macOS: Prevent unwanted native fullscreen (Spaces) toggles when the window is in fullscreen or isn't resizable. Fixes bug #3691.
Sam Lantinga 8fc1fb08 2017-08-29T21:42:22 Fixed bug 3719 - Cocoa - Incorrect window size when leaving fullscreen bastien.bouclet When exiting a "fullscreen space" on OS X, windows don't go to their defined "windowed mode size", but go back to their previous size. Steps to reproduce: 1. Create a windowed mode SDL window 2. Toggle it to fullscreen with the SDL_WINDOW_FULLSCREEN_DESKTOP flag 3. While in fullscreen, change the windowed mode size using SDL_SetWindowSize 4. Toggle the window back to windowed mode Expected result: - The window has the size specified during step 3. Actual result: - The window has the size specified when creating the window in step 1. Attached is a minimal reproduction test case. The attached test case works as expected on X11 and Windows.
Sam Lantinga 997c69b9 2017-08-01T20:16:10 Fixed bug 3697 - Main thread gets stuck on left mouse down Eric Wasylishen I think I found a better fix. The problem with https://hg.libsdl.org/SDL/rev/ebdc0738b1b5 is setting the styleMask to 0 clears the NSWindowStyleMaskFullScreen bit, which then confuses Cocoa later when you try to leave fullscreen. Instead I'm just clearing the NSWindowStyleMaskResizable bit, although SetWindowStyle(window, NSWindowStyleMaskFullScreen); seems to also work.
Sam Lantinga 6391cc3f 2017-08-01T20:09:23 Backed out changeset ebdc0738b1b5 for bug 3697 Eric Wasylishen Unfortunately this commit seems to have broken exiting desktop-fullscreen. - Launch testgl2. - Press alt+enter to go fullscreen-desktop - Press alt+enter again. The spinning cube will freeze, and the window stays fullscreen desktop.
Alex Szpakowski bc3ede1e 2017-07-13T22:59:02 macOS: Replace uses of deprecated Cocoa enum names with modern/consistent equivalents.
Sam Lantinga 37722d01 2017-07-10T17:07:19 Fixed bug 3697 - Main thread gets stuck on left mouse down Amruth Raj - My app runs in full screen to play video(I use SDL_WINDOW_FULLSCREEN_DESKTOP) - Cmd-tab to go out of full screen to another app - Cmd-tab again to get back to my app - Press left mouse button at one of the edges of the screen, don't release yet. After this point the main thread is stuck until I release the left mouse button and hence video rendering doesn't happen anymore. On debugging more, I see that thread 0 is stuck as shown below with sendEvent processing left mouse down. It comes out only after it receives a left mouse up. There are some frames below which show NSWindowResizing, but my window flag doesn't have SDL_WINDOW_RESIZABLE set. Thread 0:: CrBrowserMain Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fffbe13d34a mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fffbe13c797 mach_msg + 55 2 com.apple.CoreFoundation 0x00007fffa889d434 __CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fffa889c8c1 __CFRunLoopRun + 1361 4 com.apple.CoreFoundation 0x00007fffa889c114 CFRunLoopRunSpecific + 420 5 com.apple.HIToolbox 0x00007fffa7dfdebc RunCurrentEventLoopInMode + 240 6 com.apple.HIToolbox 0x00007fffa7dfdcf1 ReceiveNextEventCommon + 432 7 com.apple.HIToolbox 0x00007fffa7dfdb26 _BlockUntilNextEventMatchingListInModeWithFilter + 71 8 com.apple.AppKit 0x00007fffa6396a54 _DPSNextEvent + 1120 9 com.apple.AppKit 0x00007fffa6b127ee -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796 10 com.apple.AppKit 0x00007fffa66f568d +[NSWindow(NSWindowResizing) _mouseHysteresisCheck:withExpiration:andDistance:finalMouseLocation:] + 525 11 com.apple.AppKit 0x00007fffa65eedb5 -[NSWindow(NSWindowResizing) _hitTestWithHysteresisCheck:forEvent:allowWindowDragging:] + 394 12 com.apple.AppKit 0x00007fffa6c8f0db -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 1873 13 com.apple.AppKit 0x00007fffa6c8ca6c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 1942 14 com.apple.AppKit 0x00007fffa6c8bf0a -[NSWindow(NSEventRouting) sendEvent:] + 541 15 org.libsdl.SDL2 0x000000010d46d74a -[SDLWindow sendEvent:] + 90 16 com.apple.AppKit 0x00007fffa6b10681 -[NSApplication(NSEvent) sendEvent:] + 1145 17 org.libsdl.SDL2 0x000000010d46532b -[SDLApplication sendEvent:] + 139 18 org.libsdl.SDL2 0x000000010d466b2f Cocoa_PumpEvents + 495 19 org.libsdl.SDL2 0x000000010d44c1d5 SDL_PumpEvents_REAL + 53 20 org.libsdl.SDL2 0x000000010d44c2f5 SDL_WaitEventTimeout_REAL + 53 21 org.libsdl.SDL2 0x000000010d44c2b7 SDL_PollEvent_REAL + 23 22 org.libsdl.SDL2 0x000000010d51bb24 SDL_PollEvent + 36 23 libTest.dylib 0x000000010cf3e0e8 SDLEventProcessor::processEvents(int) + 568 24 Test 0x000000010cde6bba BrowserApp::RunAppMessageLoop(BAInstData*, CefStringBase, CefStringBase) + 810 25 Test 0x000000010ce04bbc main + 17980 26 libdyld.dylib 0x00007fffbe016235 start + 1 I further noticed that while entering full screen in SDL_cocoawindow.m NSResizableWindowMask is set. If I clear it inside windowDidEnterFullScreen, then, the issue doesn't repro. This is discussed at https://discourse.libsdl.org/t/main-thread-gets-stuck-on-left-mouse-down/22753/3 and thanks to Eric for the pointers.
Philipp Wiesemann 266816b4 2017-03-26T21:00:19 Removed newlines from error messages.
Sam Lantinga 45b774e3 2017-01-01T18:33:28 Updated copyright for 2017
Alex Szpakowski fd85f574 2016-12-23T22:49:37 Mac: back out commit 3e9b2ae41adf. It causes significant overhead on many GPUs.
Alex Szpakowski d719374c 2016-12-23T22:08:18 Mac: Fix over-saturated colors on P3 displays (e.g. the 2016 MBPs).
Sam Lantinga 354a8f27 2016-11-26T10:26:22 SDL for Mac - only enable global event tap when actually necessary (app has focus and has requested relative mouse mode or has asked for a mouse grab). in other situations the event tap impacts system performance and battery life with no benefit.
Sam Lantinga 27d4f099 2016-10-07T23:40:44 Implemented SDL_GetHintBoolean() to make it easier to check boolean hints
Ryan C. Gordon 4f4c4b62 2016-09-29T22:52:41 Added SDL_SetWindowResizable(). (thanks, Ethan!)
Sam Lantinga a13da2fa 2016-09-29T13:34:49 Generalized the hint for whether the application gets a mouse event when clicking on the window to activate it, and is now named SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH. The behavior is defined to not receive the click event, and this hint allows you to override that.
Alex Szpakowski 450fa8cd 2016-09-24T18:46:34 Use OS-provided click counts on macOS and iOS for mouse press and release events.
Sam Lantinga 29214826 2016-09-16T22:27:58 Fixed warning with Xcode 7.3.0
Alex Szpakowski 86708c3c 2016-09-13T19:51:10 Enable more compiler warnings in the Xcode projects (based on Xcode 8's suggestion), made some integer downcasts explicit.
Ryan C. Gordon 5bcf1d25 2016-08-28T19:06:31 cocoa: Fixed incorrect autorelease, noted by static analysis.
Alex Szpakowski 4a468739 2016-05-21T00:20:52 Removed Mac OS 10.5 support (bug #3137). Also fixed a warning about deprecated Carbon code when using SDL_audio (bug #3127, thanks Dominik!)
Alex Szpakowski b15efce2 2016-05-01T21:41:30 Cocoa mouse code: Replaced NSPointInRect with NSMouseInRect (thanks Eric Wasylishen!) Fixes bug #3312.
Alex Szpakowski d3835026 2016-05-01T19:51:10 Mac: replaced a deprecated CGSetLocalEventsSuppressionInterval call that I missed in commit 2f72bdfee9bb
Alex Szpakowski 88372277 2016-04-02T11:54:05 Add a new hint SDL_HINT_MAC_MOUSE_FOCUS_CLICKTHROUGH, which allows mouse click events to occur when clicking to focus a window in Mac OS X. Fixes bug #3300.
Ryan C. Gordon 3bdaf4c6 2016-01-05T02:46:10 Added SDL_SetWindowOpacity() and SDL_GetWindowOpacity(). This is currently implemented for X11, Cocoa, Windows, and DirectFB. This patch is based on work in Unreal Engine 4's fork of SDL, compliments of Epic Games.
Ryan C. Gordon 8e855f2f 2016-01-05T01:42:00 Added SDL_DROPBEGIN and SDL_DROPCOMPLETE events, plus window IDs for drops. This allows an app to know when a set of drops are coming in a grouping of some sort (for example, a user selected multiple files and dropped them all on the window with a single drag), and when that set is complete. This also adds a window ID to the drop events, so the app can determine to which window a given drop was delivered. For application-level drops (for example, you launched an app by dropping a file on its icon), the window ID will be zero.
Sam Lantinga 42065e78 2016-01-02T10:10:34 Updated copyright to 2016
Ryan C. Gordon 326b3578 2015-12-29T01:09:58 Mac: don't ignore mouse clicks on the top pixel of a window (thanks, Joshua!). Fixes Bugzilla #3190.
Ryan C. Gordon 257b7af2 2015-12-28T13:07:44 Sync up the caps/numlock state properly without sending key events. Partially fixes Bugzilla #2736 and #3125.
Ryan C. Gordon d3b323f8 2015-12-27T23:39:43 Mac: Fix keyboard state if capslock was toggled while app wasn't in foreground.
Alex Szpakowski 6a50d333 2015-11-30T03:30:35 Removed some debug prints.
Alex Szpakowski 9ddc6c34 2015-11-30T03:30:07 Mac: Fixed SDL_SetWindowFullscreen not restoring the window's original size when exiting a Space.
Sam Lantinga 5103ae9f 2015-11-09T08:55:07 one last SDL fix: restore menu bar if we destroy a fullscreen window without transitioning it back to a non-fullscreen window first
Sam Lantinga eeddb7c5 2015-11-09T08:54:56 more SDL fullscreen state tracking fixes, don't update fullscreen flags on failure to change fullscreen state
Sam Lantinga 792354d6 2015-11-09T08:54:49 SDL OSX implementation must account for the fact that going fullscreen can fail. improve the logic around retrying, make a few attempts before failing.
Sam Lantinga 2d884656 2015-11-09T08:54:42 add hacky support for failed fullscreen transitions. SDL doesn't have the concept of a fullscreen transition that failed. if the user is actively changing spaces while the app goes fullscreen, it fails to go fullscreen; now it will just try again instead of hanging around with the wrong window styles.
Alex Szpakowski f8824cb9 2015-10-23T03:37:53 Mac: Fix returning to the window's Space in OS X 10.11+ when SDL_WINDOW_FULLSCREEN_DESKTOP is used (bug #3152.)
Alex Szpakowski 6a32ca7a 2015-09-09T13:55:11 Mac: Fixed SDL_SetWindowSize to set the size of the content area of the window, rather than the total size including decorations.
Ryan C. Gordon 9e2b90e2 2015-08-14T01:20:41 Cocoa: Keep the window's screen position through SDL_SetWindowSize(). The Y coordinate is flipped in Cocoa, so if you change the height, the window will move and maybe clip against the screen edge if you don't adjust its Y coordinate to match. Possibly fixes Bugzilla #3066.
Sam Lantinga 396b3b89 2015-07-05T15:45:48 Better fix for bug 3048, don't crash if the window title is NULL
David Ludwig d0ba0c1d 2015-07-04T21:04:49 Fixed bug 3048, "Crashes in Cocoa_SetWindowTitle"
Ryan C. Gordon 65a1a3e7 2015-07-04T14:09:09 Cocoa: support drag-and-drop of multiple objects.
Sam Lantinga e8954d5d 2015-06-30T19:30:02 Hack to fix missing window decorations after toggling fullscreen mode in Mac OS X 10.10
Philipp Wiesemann 0e45984f 2015-06-21T17:33:46 Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().
Ryan C. Gordon 870df8ad 2015-05-31T00:50:30 Cocoa: ignore mouseDown events in a window's titlebar. These events accidentally slipping in sometimes appears to be a bug (or maybe new behavior) in 10.10, as previous versions of Mac OS X don't appear to ever trigger this. Thanks to Paulo Marques for pointing out the fix on the SDL mailing list! Fixes Bugzilla #2842 (again).
Sam Lantinga 6e67c949 2015-05-28T12:55:01 Fixed bug 2054 - SDL_GetError: "Unknown touch device" Volumetric The "Unknown touch device" message appears because the initial touch device setup loop uses SDL_GetTouch() as a guard for calling SDL_AddTouch(). SDL_GetTouch() will always report "Unknown touch device" since the device hasn't been added yet. The SDL_GetTouch() call is unnecessary since SDL_AddTouch() calls SDL_GetTouchIndex() to verify that the device hasn't been added yet, and SDL_GetTouchIndex() has the benefit of not reporting an error for a device it can't find.
Alex Szpakowski 262e8ef3 2015-05-26T21:51:47 Mac: Send a window resize event when the window's backing scale factor changes. The backing scale factor can change when the window moves between retina and non-retina displays. The only other way to detect such a change is to compare the output of SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize every frame, which is less than desirable, especially since the necessary app logic is likely already being executed when a window resize event is received.
Ryan C. Gordon 80916e01 2015-05-26T11:38:04 Cocoa: Fixed relative mouse mode when app loses/regains focus (thanks, Eric!). Fixes Bugzilla #2718.
Ryan C. Gordon bb437f02 2015-05-26T11:01:19 Cocoa: report SDL_WINDOWEVENT_EXPOSED events to the app (thanks, David!). Fixes Bugzilla #2644.
Sam Lantinga 2c4a6ea0 2015-05-26T06:27:46 Updated the copyright year to 2015