kmx git

Commit	Date	Message
412ceb84	2022-05-24T16:27:54	video: Only check major version in SDL_GetWindowWMInfo Since #5602, SDL is intended to have the same ABI across the whole major-version 2 cycle, so we should not check that the minor version matches the one that was used to compile an application. There are two checks that could make sense here. The first check is that the major version matches the expected major version. This is usually unnecessary and is not usually done (if we're calling into the wrong library we'll likely crash anyway), but since we have the information, we might as well continue to use it. The second check is whether the version provided by the caller is equal to or greater than a threshold version at which additional fields were added to the struct. If it is, we should populate those fields; if it is not, then we cannot. This is only useful on platforms where additional fields have genuinely been added during the lifetime of SDL 2, like Windows and DirectFB (but not X11). This commit changes the first check to be consistent about only looking at the minor version, while leaving the second check using SDL_VERSIONNUM (which will be removed or widened in SDL 3, but it's fine for now). Resolves: https://github.com/libsdl-org/SDL/issues/5711 Fixes: cd7c2f1 "Switch versioning scheme to be the same as GLib and Flatpak" Signed-off-by: Simon McVittie <smcv@collabora.com>
56665e1d	2022-05-17T12:50:13	cocoa: Try to use better system cursors. These try to pull from the .pdf files that are installed with macOS, which fit our needs better, and fall back to the most reasonable defaults available from NSCursor if we can't load them. Since these are installed under /System, they should be sandbox accessible, and if this totally fails, it should still go on, albeit with a less good cursor. Reference Issue #2123.
e9c7b519	2022-05-16T21:03:41	macOS: Fix reference counts of internal window data. Fixes crashes when destroying or recreating a window (#5664).
f871c178	2022-05-10T17:32:24	macOS: remove dead code for supporting 10.6 at runtime.
ec8fa577	2022-05-07T21:57:23	macOS: always use Objective-C ARC (automatic ref counting). Change Cocoa SDL_VideoData and SDL_WindowData implementations from C structs to Objective-C objects, since bridging between C and ObjC is easier that way.
7e636b03	2022-04-29T10:16:14	Removed log message length limitation for Apple platforms This works in conjunction with https://github.com/libsdl-org/SDL/pull/5584
b293888c	2022-04-26T19:44:34	Fixes an issue introduced via #5573 when building for i686
795744fc	2022-01-07T10:11:46	Turn off relative mouse before window checks as well
e2d268a3	2022-01-06T23:42:44	SDL_cocoamouse.m: SetRelativeMouseMode even if out of focus Should fix #3087
76afb858	2022-04-25T10:35:56	Introduces Cocoa_GetWindowDisplayIndex. This enable a proper management for dpi when switching between retina and non-retina displays.
8f964576	2022-03-19T11:01:55	Fixed parameter operation ordering for ease of reading
0517b61e	2022-03-19T11:00:00	Relative mouse mode is tied to the window with keyboard focus This isn't obvious, but makes sense when thinking about how games actually use it. This is also in line with how Windows mouse relative mode is implemented. Fixes https://github.com/libsdl-org/SDL/issues/5340
a164c9d2	2022-01-04T10:43:34	SDL_cocoawindow.m: update fullscreen toggle when SDL_SetWindowResizable called
ea0bca57	2022-01-11T14:56:56	SDL_cocoamodes.m: fix build against older SDKs. Fixes https://github.com/libsdl-org/SDL/issues/5208
4b38d4c9	2022-01-07T12:37:28	Leave the Metal view active on the window when recreating the Metal renderer Fixes https://github.com/libsdl-org/SDL/issues/5140 Also move the metal tag definition to SDL_syswm.h so it can be used by applications
120c76c8	2022-01-03T09:40:00	Updated copyright for 2022
4b112620	2022-01-02T19:11:50	SDL_cocoamodes.m (Cocoa_GetDisplayDPI): fix build using older toolchains Fixes https://github.com/libsdl-org/SDL/issues/5162
6a7b6380	2021-12-28T12:07:56	Fix macOS cursor jumping to corner on first titlebar click
a35a7d25	2021-12-25T05:00:26	Fix SigSegV from displayInfoInvalidate when changing resolution
1c41b535	2021-12-25T03:47:59	macOS: Calculate correct DPI by not using backingScaleFactor
66fbf00e	2021-12-09T10:40:18	Temporarily ignore gl_config.driver_loaded check in Cocoa_GLES_SetupWindow.
da0f76de	2021-12-07T00:38:46	cocoa: Don't round scroll deltas from trackpads Rounding the scroll deltas from trackpads causes jerky scrolling behavior by artificially amplifying the effects of very small scroll movements. We should only round events from devices with discrete scroll wheels, because we know the smallest unit of movement there is a single tick.
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
d9c44b65	2021-10-19T10:49:17	Allow Cocoa_VideoInit to succeed when current display mode has invalid flags This fixes a specific issue seen on macOS 10.14.6 where a DELL E248WFP Display connected to a 2014 Mac Mini with a scaled 1920x1080 resolution selected and SDL_Init(SDL_INIT_VIDEO) failed with the error: "The video driver did not add any displays". The underlying cause was that the current 1080p display mode did not have the flag kDisplayModeSafeFlag, the check for which was added in a963e36, with the idea that certain display modes should not be candidates for switching to in fullscreen exclusive mode. That may well be the right thing to do for filtering down a list of candidate modes, but it doesn't pay to be so picky about the current mode. After all, this current mode was set by System Preferences, the picture does appear correctly on screen, and other non-SDL based applications launch and run correctly in this mode. Therefore the fix is to have GetDisplayMode only filter out a mode based on flags if it's part of a candidate list, but if it's the current mode and it can possibly be converted to an SDL_DisplayMode, do so.
6f684f67	2021-07-29T18:20:36	cocoa: Add keyboard grab support CGSSetGlobalHotKeyOperatingMode() is not a public API, so we will only compile this in if SDL_MAC_NO_SANDBOX=1 is defined during compilation.
51c61d7c	2021-07-27T14:57:18	Run the entire Cocoa messagebox function on the main thread. This fixes bug https://github.com/libsdl-org/SDL/issues/4420
dfd3f30e	2021-07-27T14:27:37	Make Cocoa_HandleTitleButtonEvent() static since it's not used anywhere else
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
2f248a2a	2021-06-11T04:00:32	SDL_cocoaevents.m: fix build against SDK < 10.12 after commit 0dd7024d.
0dd7024d	2021-03-12T21:58:20	Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling When possible use native os functions to make a blocking call waiting for an incoming event. Previous behavior was to continuously poll the event queue with a small delay between each poll. The blocking call uses a new optional video driver event, WaitEventTimeout, if available. It is called only if an window already shown is available. If present the window is designated using the variable wakeup_window to receive a wakeup event if needed. The WaitEventTimeout function accept a timeout parameter. If positive the call will wait for an event or return if the timeout expired without any event. If the timeout is zero it will implement a polling behavior. If the timeout is negative the function will block indefinetely waiting for an event. To let the main thread sees events sent form a different thread a "wake-up" signal is sent to the main thread if the main thread is in a blocking state. The wake-up event is sent to the designated wakeup_window if present. The wake-up event is sent only if the PushEvent call is coming from a different thread. Before sending the wake-up event the ID of the thread making the blocking call is saved using the variable blocking_thread_id and it is compared to the current thread's id to decide if the wake-up event should be sent. Two new optional video device methods are introduced: WaitEventTimeout SendWakeupEvent in addition the mutex wakeup_lock which is defined and initialized but only for the drivers supporting the methods above. If the methods are not present the system behaves as previously performing a periodic polling of the events queue. The blocking call is disabled if a joystick or sensor is detected and falls back to previous behavior.
9dc97afa	2021-05-08T12:39:50	cocoa: Report an error if SDL_SetClipboardText() isn't using UTF-8 encoding. Fixes #4110.
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()
9ef0b97c	2021-04-12T11:25:44	Changes to macOS event handler to better interact with the running app - Only focus a new window when one closes if the window that was closed was an SDL window - If the application already has a key window set that is not an SDL window, don't replace it when the application is activated - Only register the URL event handler when SDLAppDelegate is going to be set as the applications app delegate. This is to be consistent with previous behavior that would only register the handler in -[SDLAppDelegate applicationDidFinishLaunching:] and allows the running app to opt out of the behavior by setting its own app delegate. - The URL event handler is now removed if it was set on SDLAppDelegate dealloc
033c0abb	2021-03-27T14:04:00	Use dispatch_async for -[NSOpenGLContext update]. Fixes #3680
0052339b	2021-02-20T19:53:44	Move handleURLEvent setEventHandler to init
cef198c9	2021-02-01T08:55:48	Fixed bug 5524 - Pass NSString to NSLog() Hiroyuki Iwatsuki If you pass the C string directly to NSLog(), it will be garbled with Japanese and probably other language strings, or no log will be output at all. NSLog("Hello, World!"); // => "Hello, World!" NSLog("こんにちは、世界！"); // => No output... Therefore, you need to convert the string to an NSString before passing it to NSLog(). NSString *str = [NSString stringWithUTF8String:"こんにちは、世界！"]; NSLog(@"%@", str); // => "こんにちは、世界！" Thank you.
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
963c9495	2021-01-02T10:11:08	Fixed bug 5431 - SDL_Metal_GetDrawableSize is inaccurate for high dpi displays if a Metal view has not already been created Caleb Cornett For a window created with SDL_WINDOW_ALLOW_HIGHDPI, SDL_GL_GetDrawableSize will return the high-dpi drawable size even before any GL context creation happens. But SDL_Metal_GetDrawableSize will return the size of the window if the Metal view has not been created. This is confusing and inconsistent behavior. An easy way to test this is to build testgl2 and testvulkan on macOS with the SDL_WINDOW_ALLOW_HIGHDPI flag enabled during window creation. The GL2 program will report a drawable size of 2x window width and 2x window height, while the Vulkan program will report the window size. This patch addresses the issue by falling back to using the content view dimensions if no Metal view exists in the window. (The code for this was taken directly from Cocoa_GL_GetDrawableSize.) With this change, the testvulkan behavior matches that of testgl2. Note that I haven't tested for this issue on UIKit. It's possible a similar change will need to be made there too.
90456670	2020-12-17T14:11:00	more "'for' loop initial declarations are only allowed in C99 mode" fixes
ee85a41a	2020-12-13T02:10:46	Fixed compile warning
5c212cb0	2020-12-10T12:24:24	remove a few stale NULL message/title checks after commit e2b729b1756a top-level guarantees non-NULL message / title passed in messageboxdata
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.
b79832ba	2020-10-08T21:11:09	cocoa: Cut and paste from HTML strikes again!
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.
69fbd60d	2020-10-09T04:00:00	Fix https://bugzilla.libsdl.org/show_bug.cgi?id=4877#c2 loadNibNamed:owner:topLevelObjects is available on 10.8 and newer. There is an issue report here about an app failing to function on 10.7 and earlier: https://discourse.libsdl.org/t/28179
76980e30	2020-10-08T16:42:20	Added events for dynamically connecting and disconnecting displays, with an iOS implementation
1b6de9a9	2020-09-05T15:01:45	Fix SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH=1 on Metal windows SDL_cocoametalview was consuming the first click rather than passing it through to the SDLView underneath which overrides [NSView acceptsFirstMouse] based on the user's SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH preference.
b5affd12	2020-07-16T13:28:59	Patched to compile.
8babda2c	2020-07-16T13:18:19	egl: SDL_EGL_LoadLibaryOnly() shouldn't set _this->gl_config.driver_loaded = 1 This is handled in in the higher-level SDL_GL_LoadLibrary(). All uses of SDL_EGL_LoadLibrary (which calls the Only version) are just target-specific wrappers for their own GL_LoadLibrary hook, with two exceptions which now handle driver_loaded correctly (although it's questionable if these init-if-no-one-did-it-correctly-already code blocks should exist at all, fwiw). Fixes Bugzilla #5190.
052a1373	2020-07-12T19:11:15	Merge VideoBootStrap::available into VideoBootStrap::create The two are only ever called together, and combining them makes it possible to eliminate redundant symbol loading and redundant attempts to connect to a display server.
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.
fa23e3d0	2020-05-04T02:27:29	locale: Implemented SDL_GetPreferredLocales(). This was something I proposed a long time ago, Sylvain Becker did additional work on it, then back to me. Fixes Bugzilla #2131.
a7916890	2020-04-10T00:37:35	metal: Added some support interfaces to Apple's Metal API (thanks, Caleb!). Caleb Cornett's comments: "A few weeks ago, Alex added a partial Metal API to SDL2: https://hg.libsdl.org/SDL/rev/22c8e7cd8d38 I noticed it was missing a few features that would help Metal become a first-class citizen in SDL, so I went ahead and wrote them! Here are the new APIs: 1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer to specify that they intend to create a window for use with SDL_MetalView. The flag is used to ensure correct usage of the API and to prevent accidentally defaulting to OpenGL on iOS. 2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a pointer to the view's backing CAMetalLayer. This simplifies things considerably, since in the current version of the SDL_Metal API the programmer is required to bridge-cast a SDL_MetalView handle to an NSView or UIView (depending on the platform) and then extract the layer from there. SDL_Metal_GetLayer automatically handles all of that, making the operation simple and cross-platform. 3. SDL_Metal_GetDrawableSize(). This function already exists in the current SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize on Apple platforms) but was not publicly exposed. My patch exposes this function for public use. It works just like you'd expect. Tested on macOS 10.14 and iOS 12.4." Fixes Bugzilla #4796.
6e6b5177	2020-04-07T23:34:41	cocoa: Patched to compile.
309d6137	2020-04-07T14:01:25	cocoa: OpenGL setView and update must be used on main thread (thanks, Tim!). If called from background threads, use Grand Central Dispatch to use the main thread instead. On the main thread, just call them directly. Fixes Bugzilla #4932.
b6afbe63	2020-04-07T09:38:57	Added SDL_log.h to SDL_internal.h so logging is available everywhere
dad73b1f	2020-04-05T10:47:58	Fixed bug 5073 - SDL does not handle URL Schemes in MacOS Jason In iOS, URL Events trigger the DropFile event. I would also expect the same event to be fired on the macOS platform but this is not implemented at all in the AppDelegate.
f2ff953e	2020-03-26T13:42:56	cocoa: Just update the OpenGL context directly if on the main thread.
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
5b3b55a1	2020-03-20T11:52:18	[NSOpenGLContext update[ is prohibited outside the main thread
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.
0a6d80ab	2020-02-12T13:08:29	mac: Wait a bit before activating app at startup. This is obnoxious and wrong, but the patch that activates the Dock before activating the app fixes the _menu_ not responding on Catalina, but the first window created by the app won't have keyboard focus without a small delay inserted. This obviously needs a better solution, but it gets it limping along correctly for now.
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.
c9c89783	2020-01-29T20:09:08	Miscellaneous pending fixes
c7e1b289	2020-01-27T17:15:12	cocoa: Fix command line apps' menu bar not working on macOS Catalina. Fixes Bugzilla #4937.
a8780c6a	2020-01-16T20:49:25	Updated copyright date for 2020
20daf54f	2019-12-19T15:18:50	Added new HIDAPI driver files to the Xcode projects
597f11e5	2019-12-05T17:27:06	cocoa: Patched to compile on older compilers.
ca2c8609	2019-12-04T12:20:24	cocoa: SDL_GetDisplayDPI() should account for Retina displays. Fixes Bugzilla #4856.
7a3ae590	2019-12-03T07:12:55	Fixed bug 4877 - Add support for loading menus from a nib/xib instead of building a hardcoded minimum set Eric Shepherd Currently, SDL on Cocoa macOS creates a rudimentary menu bar programmatically if none is already present when the app is registered during setup. SDL could be much more easily and flexibly used on macOS if upon finding that no menus are currently in place, it first looked for the application's main menu nib or xib file and, if found, loaded that instead of programmatically building the menus. This would then let developers simply drop in a nib file with a menu bar defined in it and it would be installed and used automatically. Attached is a patch that does just this. It changes the SDL_cocoaevents.m file to: * In Cocoa_RegisterApp(), before calling CreateApplicationMenus(), it calls a new function, LoadMainMenuNibIfAvailable(), which attempts to load and install the main menu nib file, using the nib name fetched from the Info.plist file. If that succeeds, LoadMainMenuNibIfAvailable() returns true; otherwise false. * If LMMNIA() returns false, CreateApplicationMenus() is called to programmatically build the menus as before. * Otherwise, we're done, and using the menus from the nib/xib file! I made these changes to support a project I'm working on, and felt they were useful enough to be worth offering them for uplift. They should have zero impact on existing projects' behavior, but make Cocoa SDL development miles easier.
a963e36e	2019-10-26T15:27:51	macOS: more robust detection and switching of exclusive-fullscreen display modes (bug #4822).
59beaccd	2019-10-24T20:15:54	macOS: Expose high dpi-capable display modes on macOS 10.13+. Fixes an issue in macOS 10.15 where the displayed content would move up after entering, exiting and re-entering exclusive fullscreen when certain display modes were used (bug #4822). Bug #3949 is also related to this change.
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).

412ceb84

2022-05-24T16:27:54

video: Only check major version in SDL_GetWindowWMInfo Since #5602, SDL is intended to have the same ABI across the whole major-version 2 cycle, so we should not check that the minor version matches the one that was used to compile an application. There are two checks that could make sense here. The first check is that the major version matches the expected major version. This is usually unnecessary and is not usually done (if we're calling into the wrong library we'll likely crash anyway), but since we have the information, we might as well continue to use it. The second check is whether the version provided by the caller is equal to or greater than a threshold version at which additional fields were added to the struct. If it is, we should populate those fields; if it is not, then we cannot. This is only useful on platforms where additional fields have genuinely been added during the lifetime of SDL 2, like Windows and DirectFB (but not X11). This commit changes the first check to be consistent about only looking at the minor version, while leaving the second check using SDL_VERSIONNUM (which will be removed or widened in SDL 3, but it's fine for now). Resolves: https://github.com/libsdl-org/SDL/issues/5711 Fixes: cd7c2f1 "Switch versioning scheme to be the same as GLib and Flatpak" Signed-off-by: Simon McVittie <smcv@collabora.com>

56665e1d

2022-05-17T12:50:13

cocoa: Try to use better system cursors. These try to pull from the .pdf files that are installed with macOS, which fit our needs better, and fall back to the most reasonable defaults available from NSCursor if we can't load them. Since these are installed under /System, they should be sandbox accessible, and if this totally fails, it should still go on, albeit with a less good cursor. Reference Issue #2123.

e9c7b519

2022-05-16T21:03:41

macOS: Fix reference counts of internal window data. Fixes crashes when destroying or recreating a window (#5664).

f871c178

2022-05-10T17:32:24

macOS: remove dead code for supporting 10.6 at runtime.

ec8fa577

2022-05-07T21:57:23

macOS: always use Objective-C ARC (automatic ref counting). Change Cocoa SDL_VideoData and SDL_WindowData implementations from C structs to Objective-C objects, since bridging between C and ObjC is easier that way.

7e636b03

2022-04-29T10:16:14

Removed log message length limitation for Apple platforms This works in conjunction with https://github.com/libsdl-org/SDL/pull/5584

b293888c

2022-04-26T19:44:34

Fixes an issue introduced via #5573 when building for i686

795744fc

2022-01-07T10:11:46

Turn off relative mouse before window checks as well

e2d268a3

2022-01-06T23:42:44

SDL_cocoamouse.m: SetRelativeMouseMode even if out of focus Should fix #3087

76afb858

2022-04-25T10:35:56

Introduces Cocoa_GetWindowDisplayIndex. This enable a proper management for dpi when switching between retina and non-retina displays.

8f964576

2022-03-19T11:01:55

Fixed parameter operation ordering for ease of reading

0517b61e

2022-03-19T11:00:00

Relative mouse mode is tied to the window with keyboard focus This isn't obvious, but makes sense when thinking about how games actually use it. This is also in line with how Windows mouse relative mode is implemented. Fixes https://github.com/libsdl-org/SDL/issues/5340

a164c9d2

2022-01-04T10:43:34

SDL_cocoawindow.m: update fullscreen toggle when SDL_SetWindowResizable called

ea0bca57

2022-01-11T14:56:56

SDL_cocoamodes.m: fix build against older SDKs. Fixes https://github.com/libsdl-org/SDL/issues/5208

4b38d4c9

2022-01-07T12:37:28

Leave the Metal view active on the window when recreating the Metal renderer Fixes https://github.com/libsdl-org/SDL/issues/5140 Also move the metal tag definition to SDL_syswm.h so it can be used by applications

120c76c8

2022-01-03T09:40:00

Updated copyright for 2022

4b112620

2022-01-02T19:11:50

SDL_cocoamodes.m (Cocoa_GetDisplayDPI): fix build using older toolchains Fixes https://github.com/libsdl-org/SDL/issues/5162

6a7b6380

2021-12-28T12:07:56

Fix macOS cursor jumping to corner on first titlebar click

a35a7d25

2021-12-25T05:00:26

Fix SigSegV from displayInfoInvalidate when changing resolution

1c41b535

2021-12-25T03:47:59

macOS: Calculate correct DPI by not using backingScaleFactor

66fbf00e

2021-12-09T10:40:18

Temporarily ignore gl_config.driver_loaded check in Cocoa_GLES_SetupWindow.

da0f76de

2021-12-07T00:38:46

cocoa: Don't round scroll deltas from trackpads Rounding the scroll deltas from trackpads causes jerky scrolling behavior by artificially amplifying the effects of very small scroll movements. We should only round events from devices with discrete scroll wheels, because we know the smallest unit of movement there is a single tick.

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

d9c44b65

2021-10-19T10:49:17

Allow Cocoa_VideoInit to succeed when current display mode has invalid flags This fixes a specific issue seen on macOS 10.14.6 where a DELL E248WFP Display connected to a 2014 Mac Mini with a scaled 1920x1080 resolution selected and SDL_Init(SDL_INIT_VIDEO) failed with the error: "The video driver did not add any displays". The underlying cause was that the current 1080p display mode did not have the flag kDisplayModeSafeFlag, the check for which was added in a963e36, with the idea that certain display modes should not be candidates for switching to in fullscreen exclusive mode. That may well be the right thing to do for filtering down a list of candidate modes, but it doesn't pay to be so picky about the current mode. After all, this current mode was set by System Preferences, the picture does appear correctly on screen, and other non-SDL based applications launch and run correctly in this mode. Therefore the fix is to have GetDisplayMode only filter out a mode based on flags if it's part of a candidate list, but if it's the current mode and it can possibly be converted to an SDL_DisplayMode, do so.

6f684f67

2021-07-29T18:20:36

cocoa: Add keyboard grab support CGSSetGlobalHotKeyOperatingMode() is not a public API, so we will only compile this in if SDL_MAC_NO_SANDBOX=1 is defined during compilation.

51c61d7c

2021-07-27T14:57:18

Run the entire Cocoa messagebox function on the main thread. This fixes bug https://github.com/libsdl-org/SDL/issues/4420

dfd3f30e

2021-07-27T14:27:37

Make Cocoa_HandleTitleButtonEvent() static since it's not used anywhere else

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

2f248a2a

2021-06-11T04:00:32

SDL_cocoaevents.m: fix build against SDK < 10.12 after commit 0dd7024d.

0dd7024d

2021-03-12T21:58:20

Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling When possible use native os functions to make a blocking call waiting for an incoming event. Previous behavior was to continuously poll the event queue with a small delay between each poll. The blocking call uses a new optional video driver event, WaitEventTimeout, if available. It is called only if an window already shown is available. If present the window is designated using the variable wakeup_window to receive a wakeup event if needed. The WaitEventTimeout function accept a timeout parameter. If positive the call will wait for an event or return if the timeout expired without any event. If the timeout is zero it will implement a polling behavior. If the timeout is negative the function will block indefinetely waiting for an event. To let the main thread sees events sent form a different thread a "wake-up" signal is sent to the main thread if the main thread is in a blocking state. The wake-up event is sent to the designated wakeup_window if present. The wake-up event is sent only if the PushEvent call is coming from a different thread. Before sending the wake-up event the ID of the thread making the blocking call is saved using the variable blocking_thread_id and it is compared to the current thread's id to decide if the wake-up event should be sent. Two new optional video device methods are introduced: WaitEventTimeout SendWakeupEvent in addition the mutex wakeup_lock which is defined and initialized but only for the drivers supporting the methods above. If the methods are not present the system behaves as previously performing a periodic polling of the events queue. The blocking call is disabled if a joystick or sensor is detected and falls back to previous behavior.

9dc97afa

2021-05-08T12:39:50

cocoa: Report an error if SDL_SetClipboardText() isn't using UTF-8 encoding. Fixes #4110.

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

9ef0b97c

2021-04-12T11:25:44

Changes to macOS event handler to better interact with the running app - Only focus a new window when one closes if the window that was closed was an SDL window - If the application already has a key window set that is not an SDL window, don't replace it when the application is activated - Only register the URL event handler when SDLAppDelegate is going to be set as the applications app delegate. This is to be consistent with previous behavior that would only register the handler in -[SDLAppDelegate applicationDidFinishLaunching:] and allows the running app to opt out of the behavior by setting its own app delegate. - The URL event handler is now removed if it was set on SDLAppDelegate dealloc

033c0abb

2021-03-27T14:04:00

Use dispatch_async for -[NSOpenGLContext update]. Fixes #3680

0052339b

2021-02-20T19:53:44

Move handleURLEvent setEventHandler to init

cef198c9

2021-02-01T08:55:48

Fixed bug 5524 - Pass NSString to NSLog() Hiroyuki Iwatsuki If you pass the C string directly to NSLog(), it will be garbled with Japanese and probably other language strings, or no log will be output at all. NSLog("Hello, World!"); // => "Hello, World!" NSLog("こんにちは、世界！"); // => No output... Therefore, you need to convert the string to an NSString before passing it to NSLog(). NSString *str = [NSString stringWithUTF8String:"こんにちは、世界！"]; NSLog(@"%@", str); // => "こんにちは、世界！" Thank you.

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

963c9495

2021-01-02T10:11:08

Fixed bug 5431 - SDL_Metal_GetDrawableSize is inaccurate for high dpi displays if a Metal view has not already been created Caleb Cornett For a window created with SDL_WINDOW_ALLOW_HIGHDPI, SDL_GL_GetDrawableSize will return the high-dpi drawable size even before any GL context creation happens. But SDL_Metal_GetDrawableSize will return the size of the window if the Metal view has not been created. This is confusing and inconsistent behavior. An easy way to test this is to build testgl2 and testvulkan on macOS with the SDL_WINDOW_ALLOW_HIGHDPI flag enabled during window creation. The GL2 program will report a drawable size of 2x window width and 2x window height, while the Vulkan program will report the window size. This patch addresses the issue by falling back to using the content view dimensions if no Metal view exists in the window. (The code for this was taken directly from Cocoa_GL_GetDrawableSize.) With this change, the testvulkan behavior matches that of testgl2. Note that I haven't tested for this issue on UIKit. It's possible a similar change will need to be made there too.

90456670

2020-12-17T14:11:00

more "'for' loop initial declarations are only allowed in C99 mode" fixes

ee85a41a

2020-12-13T02:10:46

Fixed compile warning

5c212cb0

2020-12-10T12:24:24

remove a few stale NULL message/title checks after commit e2b729b1756a top-level guarantees non-NULL message / title passed in messageboxdata

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.

b79832ba

2020-10-08T21:11:09

cocoa: Cut and paste from HTML strikes again!

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.

69fbd60d

2020-10-09T04:00:00

Fix https://bugzilla.libsdl.org/show_bug.cgi?id=4877#c2 loadNibNamed:owner:topLevelObjects is available on 10.8 and newer. There is an issue report here about an app failing to function on 10.7 and earlier: https://discourse.libsdl.org/t/28179

76980e30

2020-10-08T16:42:20

Added events for dynamically connecting and disconnecting displays, with an iOS implementation

1b6de9a9

2020-09-05T15:01:45

Fix SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH=1 on Metal windows SDL_cocoametalview was consuming the first click rather than passing it through to the SDLView underneath which overrides [NSView acceptsFirstMouse] based on the user's SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH preference.

b5affd12

2020-07-16T13:28:59

Patched to compile.

8babda2c

2020-07-16T13:18:19

egl: SDL_EGL_LoadLibaryOnly() shouldn't set _this->gl_config.driver_loaded = 1 This is handled in in the higher-level SDL_GL_LoadLibrary(). All uses of SDL_EGL_LoadLibrary (which calls the Only version) are just target-specific wrappers for their own GL_LoadLibrary hook, with two exceptions which now handle driver_loaded correctly (although it's questionable if these init-if-no-one-did-it-correctly-already code blocks should exist at all, fwiw). Fixes Bugzilla #5190.

052a1373

2020-07-12T19:11:15

Merge VideoBootStrap::available into VideoBootStrap::create The two are only ever called together, and combining them makes it possible to eliminate redundant symbol loading and redundant attempts to connect to a display server.

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.

fa23e3d0

2020-05-04T02:27:29

locale: Implemented SDL_GetPreferredLocales(). This was something I proposed a long time ago, Sylvain Becker did additional work on it, then back to me. Fixes Bugzilla #2131.

a7916890

2020-04-10T00:37:35

metal: Added some support interfaces to Apple's Metal API (thanks, Caleb!). Caleb Cornett's comments: "A few weeks ago, Alex added a partial Metal API to SDL2: https://hg.libsdl.org/SDL/rev/22c8e7cd8d38 I noticed it was missing a few features that would help Metal become a first-class citizen in SDL, so I went ahead and wrote them! Here are the new APIs: 1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer to specify that they intend to create a window for use with SDL_MetalView. The flag is used to ensure correct usage of the API and to prevent accidentally defaulting to OpenGL on iOS. 2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a pointer to the view's backing CAMetalLayer. This simplifies things considerably, since in the current version of the SDL_Metal API the programmer is required to bridge-cast a SDL_MetalView handle to an NSView or UIView (depending on the platform) and then extract the layer from there. SDL_Metal_GetLayer automatically handles all of that, making the operation simple and cross-platform. 3. SDL_Metal_GetDrawableSize(). This function already exists in the current SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize on Apple platforms) but was not publicly exposed. My patch exposes this function for public use. It works just like you'd expect. Tested on macOS 10.14 and iOS 12.4." Fixes Bugzilla #4796.

6e6b5177

2020-04-07T23:34:41

cocoa: Patched to compile.

309d6137

2020-04-07T14:01:25

cocoa: OpenGL setView and update must be used on main thread (thanks, Tim!). If called from background threads, use Grand Central Dispatch to use the main thread instead. On the main thread, just call them directly. Fixes Bugzilla #4932.

b6afbe63

2020-04-07T09:38:57

Added SDL_log.h to SDL_internal.h so logging is available everywhere

dad73b1f

2020-04-05T10:47:58

Fixed bug 5073 - SDL does not handle URL Schemes in MacOS Jason In iOS, URL Events trigger the DropFile event. I would also expect the same event to be fired on the macOS platform but this is not implemented at all in the AppDelegate.

f2ff953e

2020-03-26T13:42:56

cocoa: Just update the OpenGL context directly if on the main thread.

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

5b3b55a1

2020-03-20T11:52:18

[NSOpenGLContext update[ is prohibited outside the main thread

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.

0a6d80ab

2020-02-12T13:08:29

mac: Wait a bit before activating app at startup. This is obnoxious and wrong, but the patch that activates the Dock before activating the app fixes the _menu_ not responding on Catalina, but the first window created by the app won't have keyboard focus without a small delay inserted. This obviously needs a better solution, but it gets it limping along correctly for now.

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.

c9c89783

2020-01-29T20:09:08

Miscellaneous pending fixes

c7e1b289

2020-01-27T17:15:12

cocoa: Fix command line apps' menu bar not working on macOS Catalina. Fixes Bugzilla #4937.

a8780c6a

2020-01-16T20:49:25

20daf54f

2019-12-19T15:18:50

Added new HIDAPI driver files to the Xcode projects

597f11e5

2019-12-05T17:27:06

cocoa: Patched to compile on older compilers.

ca2c8609

2019-12-04T12:20:24

cocoa: SDL_GetDisplayDPI() should account for Retina displays. Fixes Bugzilla #4856.

7a3ae590

2019-12-03T07:12:55

Fixed bug 4877 - Add support for loading menus from a nib/xib instead of building a hardcoded minimum set Eric Shepherd Currently, SDL on Cocoa macOS creates a rudimentary menu bar programmatically if none is already present when the app is registered during setup. SDL could be much more easily and flexibly used on macOS if upon finding that no menus are currently in place, it first looked for the application's main menu nib or xib file and, if found, loaded that instead of programmatically building the menus. This would then let developers simply drop in a nib file with a menu bar defined in it and it would be installed and used automatically. Attached is a patch that does just this. It changes the SDL_cocoaevents.m file to: * In Cocoa_RegisterApp(), before calling CreateApplicationMenus(), it calls a new function, LoadMainMenuNibIfAvailable(), which attempts to load and install the main menu nib file, using the nib name fetched from the Info.plist file. If that succeeds, LoadMainMenuNibIfAvailable() returns true; otherwise false. * If LMMNIA() returns false, CreateApplicationMenus() is called to programmatically build the menus as before. * Otherwise, we're done, and using the menus from the nib/xib file! I made these changes to support a project I'm working on, and felt they were useful enough to be worth offering them for uplift. They should have zero impact on existing projects' behavior, but make Cocoa SDL development miles easier.

a963e36e

2019-10-26T15:27:51

macOS: more robust detection and switching of exclusive-fullscreen display modes (bug #4822).

59beaccd

2019-10-24T20:15:54

macOS: Expose high dpi-capable display modes on macOS 10.13+. Fixes an issue in macOS 10.15 where the displayed content would move up after entering, exiting and re-entering exclusive fullscreen when certain display modes were used (bug #4822). Bug #3949 is also related to this change.

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

kc3-lang/SDL/src/video/cocoa

src/video/cocoa

Log