kmx git

Commit	Date	Message
120c76c8	2022-01-03T09:40:00	Updated copyright for 2022
6a7b6380	2021-12-28T12:07:56	Fix macOS cursor jumping to corner on first titlebar click
ceb9e9a8	2021-11-21T00:21:41	cocoa: Removed a debug printf call.
18715acb	2021-11-21T00:14:18	cocoa: Position non-left mouse button events in background windows correctly. Fixes #4828.
cc094f4d	2021-11-14T20:15:48	Fixed building with the macOS 10.8 SDK
1cd3e837	2021-11-14T15:51:38	cocoa: Fix abort on touch event types without a subtype macOS 10.6 has some touch NSEvents which do not have a subtype (Begin/EndGesture, Magnify, Rotate, Swipe) and cause an uncaught exception which triggers SIGABRT and the program exits. As it is, none of the macOS 10.6 touch events are detected as a trackpad (including Gesture due to using different subtypes).
074e613b	2021-11-12T03:03:56	Fixed typo
35d90f17	2021-11-12T03:00:57	Better implementation of SDL_SetWindowMouseGrab() and SDL_SetWindowMouseRect() on macOS
fd79607e	2021-11-08T21:34:48	Added SDL_GetWindowMouseRect() Also guarantee that we won't get mouse movement outside the confining area, even if the OS implementation allows it (e.g. macOS)
4db546b0	2021-11-08T20:35:12	Implemented SDL_SetWindowMouseRect() on macOS
ba4ef461	2021-10-23T15:28:13	macOS: Fix implicit integer downcast warnings
19dee1cd	2021-10-22T06:37:20	Add SDL_GetWindowICCProfile(). (#4314) * Add SDL_GetWindowICCProfile * Add new SDL display events * Implement ICC profile change event for macOS * Implement ICC profile notification for Windows * Fix SDL_GetWindowICCProfile() for X11 * Fix compile errors
88e4755c	2021-07-27T12:43:00	Make sure we don't try to turn on relative mouse mode while clicking on the window title bar. This fixes bug https://github.com/libsdl-org/SDL/issues/4469
f1633127	2021-07-24T13:41:55	Added a window flash operation to be explicit about window flash behavior
e1c3a250	2021-07-24T12:11:27	Changed SDL_FlashWindow() so it doesn't take a flash count, and added the hint SDL_HINT_WINDOW_FLASH_COUNT to control behavior on Windows
56b77b12	2021-06-04T19:51:58	cocoa: Implement FlashWindow
8527c583	2021-04-27T01:36:23	cocoa: Fix recreated windows that are both borderless and resizable. These would accidentally get a titlebar because the "borderless" style mask is zero but the resizable attribute adds a bit. I assume this happens because you used to need window decoration to resize a window in macOS, but this changed in later releases. This only caused problems when recreating a window (you had an SDL_WINDOW_OPENGL window and tried to create a Metal SDL_Renderer on it, etc). Fixes #4324.
2fdbae22	2021-04-26T18:43:28	cocoa: Remove mouse event tap. It doesn't appear to work anymore, and was disabled by default anyhow, since the needed APIs are forbidden on the Mac App Store. A better solution to lock the mouse to the window on macOS would still be welcome. CGAssociateMouseAndMouseCursorPosition() works fine for relative mouse mode, this was just a question of SDL_SetWindowGrab(). As it stands now, a grabbed mouse can briefly break out of the window, causing varying degrees of chaos.
a0a5da5d	2021-04-19T07:13:38	Add SDL_SetWindowAlwaysOnTop()
6b057c67	2021-01-26T19:16:17	Expose separate keyboard and mouse grab support This adds SDL_SetWindowKeyboardGrab(), SDL_GetWindowKeyboardGrab(), SDL_SetWindowMouseGrab(), SDL_GetWindowMouseGrab(), and new SDL_WINDOW_KEYBOARD_GRABBED flag. It also updates the test harness to exercise this functionality and makes a minor fix to X11 that I missed in https://hg.libsdl.org/SDL/rev/02a2d609369b To fit in with this new support, SDL_WINDOW_INPUT_CAPTURE has been renamed to SDL_WINDOW_MOUSE_CAPTURE with the old name remaining as an alias for backwards compatibility with older code.
a0d3c6c6	2021-01-25T21:42:14	Rename SetWindowGrab() to SetWindowMouseGrab()
e778881a	2021-01-07T11:49:28	Fixed bug 5449 - SDL_DROPFILE update mouse location of drop in Cocoa Dominik Reichardt Exult (http://exult.info) has an editor app that uses GTK+2. Up to now we were using X's drag'n'drop to allow dropping of assets from the editor onto Exult. There is now an experimental branch that makes use of SDL_DROPFILE. That works under X, dropping in Exult's SDL2 window puts the asset right at the spot you dropped at. On macOS with native Exult and Quartz GTK+2 this doesn't work, the location of the drop is where the mouse was last tracked before you left the window (usually one of the edges, unless you tabbed out). All we tried out pointed to the fact that the location update needs to be done by the dropfile event in SDL2, not by our own (which always only worked after the Exult window getting focus). This patch adds this to SDL_cocoawindow.m and it works perfectly, passing the correct coordinates to our code (SDL_GetMouseState()).
9130f7c3	2021-01-02T10:25:38	Updated copyright for 2021
cb361896	2020-12-09T07:16:22	Fixed bug 5235 - All internal sources should include SDL_assert.h Ryan C. Gordon We should really stick this in SDL_internal.h or something so it's always available.
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.
97ca96bd	2020-05-27T10:13:01	Use nil instead of NULL for Objective-C objects
af5eb56c	2020-05-27T09:28:03	Fixed uninitialized variable warning
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.
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.
6e6b5177	2020-04-07T23:34:41	cocoa: Patched to compile.
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.
1fd548b6	2020-03-23T11:42:44	Fixed building back to Mac OSX using the 10.7 SDK
51e9e984	2020-03-01T13:00:50	Fixed whitespace
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
094655cf	2020-02-23T14:49:03	cocoa: Make sure wait for button enable can't be infinite.
72316518	2020-02-23T14:48:48	cocoa: Removed a debug printf that was accidentally committed.
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.
fe8ce66b	2020-02-11T10:35:14	Attempt to make version detection safe for Mac OS X < 10.10
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.
a8780c6a	2020-01-16T20:49:25	Updated copyright date for 2020
d5e378d1	2019-10-15T00:59:10	cocoa: Implement SDL_WINDOW_ALWAYS_ON_TOP support (thanks, Gabriel!). Fixes Bugzilla #4809.
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).
009226c6	2019-10-13T21:39:20	macOS: Fix non-highdpi OpenGL contexts not scaling properly in macOS 10.15 (bug 4810 and 4822).
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).
f3683d3a	2019-08-04T23:30:55	macOS: fix a typo in touch handling code.
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.
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.
27ad8e5d	2019-07-11T01:07:14	cocoa: Set keyboard mod state correctly when turning off capslock. Fixes Bugzilla #4716.
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.
d2d06f44	2019-07-02T12:29:36	cocoa: Don't report trackpad mouse events as synthesized touches. Fixes Bugzilla #4690, sort of. I guess.
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.
ed8b78d3	2019-06-14T21:18:53	cocoa: ignore compiler warnings about OpenGL being deprecated.
90e2dc98	2019-06-14T18:23:51	A few minor changes to placate static analysis.
d9a2eff2	2019-06-13T21:31:03	cocoa: Another attempt at synthesized mouse/touch events.
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!)
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.
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.
5e13087b	2019-01-04T22:01:14	Updated copyright for 2019
bd08d72d	2018-12-11T20:04:10	Fixed building with the 10.10 SDK
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.
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;
c525ff35	2018-11-10T20:56:23	cocoa: fix building with the macOS 10.7 SDK (thanks Riccardo!) Fixes bug #4368
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.
cad0a2f7	2018-10-18T12:05:05	cocoa: Fix OpenGL rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272. (transplanted from 54729119b348e8a4a916192d1d6cb8d115656255)
f6773773	2018-10-18T12:05:05	cocoa: Fix OpenGL rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272.
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)
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.
5febdfce	2018-09-24T11:49:25	Fixed whitespace
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.
e3cc5b2c	2018-01-03T10:03:25	Updated copyright for 2018
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.
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.
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.
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).
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
d7ae3131	2017-08-31T21:34:29	macOS: Fix menubar items being enabled when they shouldn't be.
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.
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.
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.
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.
bc3ede1e	2017-07-13T22:59:02	macOS: Replace uses of deprecated Cocoa enum names with modern/consistent equivalents.
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.
266816b4	2017-03-26T21:00:19	Removed newlines from error messages.
45b774e3	2017-01-01T18:33:28	Updated copyright for 2017
fd85f574	2016-12-23T22:49:37	Mac: back out commit 3e9b2ae41adf. It causes significant overhead on many GPUs.
d719374c	2016-12-23T22:08:18	Mac: Fix over-saturated colors on P3 displays (e.g. the 2016 MBPs).
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.
27d4f099	2016-10-07T23:40:44	Implemented SDL_GetHintBoolean() to make it easier to check boolean hints
4f4c4b62	2016-09-29T22:52:41	Added SDL_SetWindowResizable(). (thanks, Ethan!)
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.
450fa8cd	2016-09-24T18:46:34	Use OS-provided click counts on macOS and iOS for mouse press and release events.
29214826	2016-09-16T22:27:58	Fixed warning with Xcode 7.3.0
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.
5bcf1d25	2016-08-28T19:06:31	cocoa: Fixed incorrect autorelease, noted by static analysis.
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!)
b15efce2	2016-05-01T21:41:30	Cocoa mouse code: Replaced NSPointInRect with NSMouseInRect (thanks Eric Wasylishen!) Fixes bug #3312.
d3835026	2016-05-01T19:51:10	Mac: replaced a deprecated CGSetLocalEventsSuppressionInterval call that I missed in commit 2f72bdfee9bb
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.
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.
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.

120c76c8

2022-01-03T09:40:00

Updated copyright for 2022

6a7b6380

2021-12-28T12:07:56

Fix macOS cursor jumping to corner on first titlebar click

ceb9e9a8

2021-11-21T00:21:41

cocoa: Removed a debug printf call.

18715acb

2021-11-21T00:14:18

cocoa: Position non-left mouse button events in background windows correctly. Fixes #4828.

cc094f4d

2021-11-14T20:15:48

Fixed building with the macOS 10.8 SDK

1cd3e837

2021-11-14T15:51:38

cocoa: Fix abort on touch event types without a subtype macOS 10.6 has some touch NSEvents which do not have a subtype (Begin/EndGesture, Magnify, Rotate, Swipe) and cause an uncaught exception which triggers SIGABRT and the program exits. As it is, none of the macOS 10.6 touch events are detected as a trackpad (including Gesture due to using different subtypes).

074e613b

2021-11-12T03:03:56

Fixed typo

35d90f17

2021-11-12T03:00:57

Better implementation of SDL_SetWindowMouseGrab() and SDL_SetWindowMouseRect() on macOS

fd79607e

2021-11-08T21:34:48

Added SDL_GetWindowMouseRect() Also guarantee that we won't get mouse movement outside the confining area, even if the OS implementation allows it (e.g. macOS)

4db546b0

2021-11-08T20:35:12

Implemented SDL_SetWindowMouseRect() on macOS

ba4ef461

2021-10-23T15:28:13

macOS: Fix implicit integer downcast warnings

19dee1cd

2021-10-22T06:37:20

Add SDL_GetWindowICCProfile(). (#4314) * Add SDL_GetWindowICCProfile * Add new SDL display events * Implement ICC profile change event for macOS * Implement ICC profile notification for Windows * Fix SDL_GetWindowICCProfile() for X11 * Fix compile errors

88e4755c

2021-07-27T12:43:00

Make sure we don't try to turn on relative mouse mode while clicking on the window title bar. This fixes bug https://github.com/libsdl-org/SDL/issues/4469

f1633127

2021-07-24T13:41:55

Added a window flash operation to be explicit about window flash behavior

e1c3a250

2021-07-24T12:11:27

Changed SDL_FlashWindow() so it doesn't take a flash count, and added the hint SDL_HINT_WINDOW_FLASH_COUNT to control behavior on Windows

56b77b12

2021-06-04T19:51:58

cocoa: Implement FlashWindow

8527c583

2021-04-27T01:36:23

cocoa: Fix recreated windows that are both borderless and resizable. These would accidentally get a titlebar because the "borderless" style mask is zero but the resizable attribute adds a bit. I assume this happens because you used to need window decoration to resize a window in macOS, but this changed in later releases. This only caused problems when recreating a window (you had an SDL_WINDOW_OPENGL window and tried to create a Metal SDL_Renderer on it, etc). Fixes #4324.

2fdbae22

2021-04-26T18:43:28

cocoa: Remove mouse event tap. It doesn't appear to work anymore, and was disabled by default anyhow, since the needed APIs are forbidden on the Mac App Store. A better solution to lock the mouse to the window on macOS would still be welcome. CGAssociateMouseAndMouseCursorPosition() works fine for relative mouse mode, this was just a question of SDL_SetWindowGrab(). As it stands now, a grabbed mouse can briefly break out of the window, causing varying degrees of chaos.

a0a5da5d

2021-04-19T07:13:38

Add SDL_SetWindowAlwaysOnTop()

6b057c67

2021-01-26T19:16:17

Expose separate keyboard and mouse grab support This adds SDL_SetWindowKeyboardGrab(), SDL_GetWindowKeyboardGrab(), SDL_SetWindowMouseGrab(), SDL_GetWindowMouseGrab(), and new SDL_WINDOW_KEYBOARD_GRABBED flag. It also updates the test harness to exercise this functionality and makes a minor fix to X11 that I missed in https://hg.libsdl.org/SDL/rev/02a2d609369b To fit in with this new support, SDL_WINDOW_INPUT_CAPTURE has been renamed to SDL_WINDOW_MOUSE_CAPTURE with the old name remaining as an alias for backwards compatibility with older code.

a0d3c6c6

2021-01-25T21:42:14

Rename SetWindowGrab() to SetWindowMouseGrab()

e778881a

2021-01-07T11:49:28

Fixed bug 5449 - SDL_DROPFILE update mouse location of drop in Cocoa Dominik Reichardt Exult (http://exult.info) has an editor app that uses GTK+2. Up to now we were using X's drag'n'drop to allow dropping of assets from the editor onto Exult. There is now an experimental branch that makes use of SDL_DROPFILE. That works under X, dropping in Exult's SDL2 window puts the asset right at the spot you dropped at. On macOS with native Exult and Quartz GTK+2 this doesn't work, the location of the drop is where the mouse was last tracked before you left the window (usually one of the edges, unless you tabbed out). All we tried out pointed to the fact that the location update needs to be done by the dropfile event in SDL2, not by our own (which always only worked after the Exult window getting focus). This patch adds this to SDL_cocoawindow.m and it works perfectly, passing the correct coordinates to our code (SDL_GetMouseState()).

9130f7c3

2021-01-02T10:25:38

Updated copyright for 2021

cb361896

2020-12-09T07:16:22

Fixed bug 5235 - All internal sources should include SDL_assert.h Ryan C. Gordon We should really stick this in SDL_internal.h or something so it's always available.

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.

97ca96bd

2020-05-27T10:13:01

Use nil instead of NULL for Objective-C objects

af5eb56c

2020-05-27T09:28:03

Fixed uninitialized variable warning

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.

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.

6e6b5177

2020-04-07T23:34:41

cocoa: Patched to compile.

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.

1fd548b6

2020-03-23T11:42:44

Fixed building back to Mac OSX using the 10.7 SDK

51e9e984

2020-03-01T13:00:50

Fixed whitespace

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

094655cf

2020-02-23T14:49:03

cocoa: Make sure wait for button enable can't be infinite.

72316518

2020-02-23T14:48:48

cocoa: Removed a debug printf that was accidentally committed.

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.

fe8ce66b

2020-02-11T10:35:14

Attempt to make version detection safe for Mac OS X < 10.10

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.

a8780c6a

2020-01-16T20:49:25

Updated copyright date for 2020

d5e378d1

2019-10-15T00:59:10

cocoa: Implement SDL_WINDOW_ALWAYS_ON_TOP support (thanks, Gabriel!). Fixes Bugzilla #4809.

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).

009226c6

2019-10-13T21:39:20

macOS: Fix non-highdpi OpenGL contexts not scaling properly in macOS 10.15 (bug 4810 and 4822).

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).

f3683d3a

2019-08-04T23:30:55

macOS: fix a typo in touch handling code.

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.

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.

27ad8e5d

2019-07-11T01:07:14

cocoa: Set keyboard mod state correctly when turning off capslock. Fixes Bugzilla #4716.

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.

d2d06f44

2019-07-02T12:29:36

cocoa: Don't report trackpad mouse events as synthesized touches. Fixes Bugzilla #4690, sort of. I guess.

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.

ed8b78d3

2019-06-14T21:18:53

cocoa: ignore compiler warnings about OpenGL being deprecated.

90e2dc98

2019-06-14T18:23:51

A few minor changes to placate static analysis.

d9a2eff2

2019-06-13T21:31:03

cocoa: Another attempt at synthesized mouse/touch events.

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!)

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.

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.

5e13087b

2019-01-04T22:01:14

Updated copyright for 2019

bd08d72d

2018-12-11T20:04:10

Fixed building with the 10.10 SDK

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.

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;

c525ff35

2018-11-10T20:56:23

cocoa: fix building with the macOS 10.7 SDK (thanks Riccardo!) Fixes bug #4368

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.

cad0a2f7

2018-10-18T12:05:05

cocoa: Fix OpenGL rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272. (transplanted from 54729119b348e8a4a916192d1d6cb8d115656255)

f6773773

2018-10-18T12:05:05

cocoa: Fix OpenGL rendering on macOS 10.14 ("Mojave"). Fixes Bugzilla #4272.

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)

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.

5febdfce

2018-09-24T11:49:25

Fixed whitespace

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.

e3cc5b2c

2018-01-03T10:03:25

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.

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.

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.

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).

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

d7ae3131

2017-08-31T21:34:29

macOS: Fix menubar items being enabled when they shouldn't be.

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.

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.

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.

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.

bc3ede1e

2017-07-13T22:59:02

macOS: Replace uses of deprecated Cocoa enum names with modern/consistent equivalents.

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.

266816b4

2017-03-26T21:00:19

Removed newlines from error messages.

45b774e3

2017-01-01T18:33:28

fd85f574

2016-12-23T22:49:37

Mac: back out commit 3e9b2ae41adf. It causes significant overhead on many GPUs.

d719374c

2016-12-23T22:08:18

Mac: Fix over-saturated colors on P3 displays (e.g. the 2016 MBPs).

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.

27d4f099

2016-10-07T23:40:44

Implemented SDL_GetHintBoolean() to make it easier to check boolean hints

4f4c4b62

2016-09-29T22:52:41

Added SDL_SetWindowResizable(). (thanks, Ethan!)

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.

450fa8cd

2016-09-24T18:46:34

Use OS-provided click counts on macOS and iOS for mouse press and release events.

29214826

2016-09-16T22:27:58

Fixed warning with Xcode 7.3.0

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.

5bcf1d25

2016-08-28T19:06:31

cocoa: Fixed incorrect autorelease, noted by static analysis.

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!)

b15efce2

2016-05-01T21:41:30

Cocoa mouse code: Replaced NSPointInRect with NSMouseInRect (thanks Eric Wasylishen!) Fixes bug #3312.

d3835026

2016-05-01T19:51:10

Mac: replaced a deprecated CGSetLocalEventsSuppressionInterval call that I missed in commit 2f72bdfee9bb

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.

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.

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.

kc3-lang/SDL/src/video/cocoa/SDL_cocoawindow.m

src/video/cocoa/SDL_cocoawindow.m

Log