|
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).
|
|
|
009226c6
|
2019-10-13T21:39:20
|
|
macOS: Fix non-highdpi OpenGL contexts not scaling properly in macOS 10.15 (bug 4810 and 4822).
|
|
|
f8bdefe1
|
2019-10-13T15:18:28
|
|
macOS: Fix asserts in SDL_Render's metal scissor code when the window is resized.
|
|
|
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).
|
|
|
dd29abb4
|
2019-08-22T19:23:52
|
|
macOS: Use the proper type (NSSize instead of CGSize) for the bounds of metal views.
|
|
|
aebaa316
|
2019-08-05T12:35:32
|
|
Add public APIs for creating a Metal view attached to an SDL window. Add SDL_metal.h.
|
|
|
f3683d3a
|
2019-08-04T23:30:55
|
|
macOS: fix a typo in touch handling code.
|
|
|
63197c43
|
2019-08-02T17:19:50
|
|
Fix bug where the wrong button was the default in the old message box because buttons were added backwards, breaking the indexing used by GetButtonIndex.
Add messagebox flags to explicilty request left-to-right button order or right-to-left. If neither is specified it'll be some platform default.
|
|
|
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.
|
|
|
31cb854f
|
2019-07-30T10:04:46
|
|
Fixed bug 4745 - 2.0.10 fails to build against macOS 10.11 SDK
Joshua Root
NSEventSubtypeMouseEvent was added in 10.12, so it needs to be defined on 10.11 as well
|
|
bf9bf602
|
2019-07-17T23:20:57
|
|
Copypaste SDL_NSLog to UIKit backend, document it as such
|
|
|
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.
|
|
|
d3bedda4
|
2019-06-18T16:53:49
|
|
cocoa: Patched to compile and also handle possible malloc failure.
|
|
|
3e720d2a
|
2019-06-18T13:41:38
|
|
Fixed potential double-free in mouse cleanup code
|
|
|
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!)
|
|
|
50f51231
|
2019-06-12T19:57:30
|
|
macOS: Fix the coordinate space of SDL_GetDisplayUsableBounds (thanks Tim!)
Fixes bug #4518.
|
|
|
69d27a69
|
2019-06-11T18:13:46
|
|
Fixed bug 4570 - Support Vulkan Portability rather than MoltenVK specifically
Dzmitry Malyshau
Current code, search paths, and error messages are written to only consider MoltenVK on macOS as a Vulkan Portability implementation. It's not the only implementation available to the users. gfx-portability [1] has been shown to run a number of titles well, including Dota2, Dolphin Emulator, and vkQuake3, often out-performing MoltenVK in frame rate and stability (see Dolphin benchmark [2]).
There is no reason for SDL to be that specific, it's not using any MVK-specific functions other than the WSI initialization ("VK_MVK_macos_surface"). gfx-portability exposes this extension as well, and a more generic WSI extension is in process. It would be good if SDL was written in a more generic way that expect a Vulkan Portability library as opposed to MoltenVK specifically.
[1] https://github.com/gfx-rs/portability
[2] https://gfx-rs.github.io/2019/03/22/dolphin-macos-performance.html
|
|
|
04b50f6c
|
2019-06-11T16:19:01
|
|
cocoa: Backed out CVDisplayLink code for macOS vsync.
This was to deal with broken vsync support in macOS 10.14, which we assumed
would remain broken indefinitely, but a later 10.14 released fixed it.
This is a loss of late-swap support, but there are several subtle problems
in our CVDiplayLink code that are also evaporating, to be fair.
Fixes Bugzilla #4575.
(Backed out changeset 8760fed23001)
|
|
|
aa80d279
|
2019-06-11T08:33:30
|
|
Fix build with the 10.10 SDK
|
|
|
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.
|
|
|
9d7b2615
|
2019-04-17T20:14:40
|
|
macOS: Fix compilation when using the 10.9 SDK or older.
|
|
|
00c824a8
|
2019-04-10T22:30:58
|
|
Fix disabling OpenGL vsync on macOS 10.14.4+ (bug #4575).
|
|
|
0442d19f
|
2019-03-04T12:16:43
|
|
cocoa: Fix assert to use SDL_assert
|
|
|
d4c0f498
|
2019-01-04T22:09:38
|
|
Fixed bug 4255 - SDL_GetGlobalMouseState() returns incorrect Y on secondary display
Julian Raschke
I use an open Mac laptop with an additional external monitor. The coordinate spaces from SDL_GetGlobalMouseState() and SDL_GetWindowPosition() match on the primary display, but not on the secondary display.
Cocoa window coordinates are vertically flipped in relation to the primary display:
https://github.com/spurious/SDL-mirror/blob/release-2.0.8/src/video/cocoa/SDL_cocoawindow.m#L219-L222
However, Cocoa_GetGlobalMouseState inverts the cursor Y coordinate per-display:
https://github.com/spurious/SDL-mirror/blob/release-2.0.8/src/video/cocoa/SDL_cocoamouse.m#L320-L323
Suggested fix: Replace the for-loop with this simpler calculation:
*x = (int) cocoaLocation.x;
*y = (int) (CGDisplayPixelsHigh(kCGDirectMainDisplay) - cocoaLocation.y);
|
|
|
5e13087b
|
2019-01-04T22:01:14
|
|
Updated copyright for 2019
|
|
|
13869f19
|
2018-12-16T01:03:17
|
|
cocoa: Implement OpenGL swap interval support with CVDisplayLink.
Not only does this fix macOS 10.14 ("Mojave")'s broken NSOpenGLCPSwapInterval
support, it also lets us implement "adaptive vsync" on macOS!
CVDisplayLink is supported back to macOS 10.4 ("Tiger"), so we just use it
universally without version checks and dump NSOpenGLCPSwapInterval, Mojave or
not.
|
|
|
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.
|
|
|
62494a2e
|
2018-10-31T15:03:41
|
|
Merge SDL-ryan-batching-renderer branch to default.
|
|
|
b262b0eb
|
2018-10-22T20:50:32
|
|
Small stack allocations fall back to malloc if they're unexpectedly large.
|