Commit Graph

210 Commits

Author SHA1 Message Date
Ryan C. Gordon
b79832ba11 cocoa: Cut and paste from HTML strikes again! 2020-10-08 21:11:09 -04:00
Ozkan Sezer
19aaa2944d 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.
2020-10-09 04:00:00 +03:00
Ozkan Sezer
69fbd60d25 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
2020-10-09 04:00:00 +03:00
Sam Lantinga
76980e30f2 Added events for dynamically connecting and disconnecting displays, with an iOS implementation 2020-10-08 16:42:20 -07:00
Cameron Gutman
1b6de9a987 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.
2020-09-05 15:01:45 -07:00
Ryan C. Gordon
b5affd12e6 Patched to compile. 2020-07-16 13:28:59 -04:00
Ryan C. Gordon
8babda2c20 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.
2020-07-16 13:18:19 -04:00
M Stoeckl
052a13738d 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.
2020-07-12 19:11:15 -04:00
Cameron Gutman
77b0dad271 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.
2020-05-25 20:55:29 -07:00
Sam Lantinga
97ca96bdee Use nil instead of NULL for Objective-C objects 2020-05-27 10:13:01 -07:00
Sam Lantinga
af5eb56c76 Fixed uninitialized variable warning 2020-05-27 09:28:03 -07:00
Sam Lantinga
b47f577a9d 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.
2020-05-11 14:36:23 -07:00
Ryan C. Gordon
fa23e3d00b 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.
2020-05-04 02:27:29 -04:00
Ryan C. Gordon
a791689086 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.
2020-04-10 00:37:35 -04:00
Ryan C. Gordon
6e6b517789 cocoa: Patched to compile. 2020-04-07 23:34:41 -04:00
Michael Maltese
361417c0a4 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.
2020-03-25 16:40:43 -07:00
Ryan C. Gordon
309d6137ae 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.
2020-04-07 14:01:25 -04:00
Sam Lantinga
b6afbe6317 Added SDL_log.h to SDL_internal.h so logging is available everywhere 2020-04-07 09:38:57 -07:00
Sam Lantinga
dad73b1f0c 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.
2020-04-05 10:47:58 -07:00
Ryan C. Gordon
f2ff953ef7 cocoa: Just update the OpenGL context directly if on the main thread. 2020-03-26 13:42:56 -04:00
Sam Lantinga
1fd548b67a Fixed building back to Mac OSX using the 10.7 SDK 2020-03-23 11:42:44 -07:00
Emir Marincic
5b3b55a181 [NSOpenGLContext update[ is prohibited outside the main thread 2020-03-20 11:52:18 +03:00
Sam Lantinga
51e9e98451 Fixed whitespace 2020-03-01 13:00:50 -08:00
Sam Lantinga
8a6f1aa5f5 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
2020-03-01 12:58:50 -08:00
Ryan C. Gordon
094655cff9 cocoa: Make sure wait for button enable can't be infinite. 2020-02-23 14:49:03 -05:00
Ryan C. Gordon
723165187f cocoa: Removed a debug printf that was accidentally committed. 2020-02-23 14:48:48 -05:00
Ryan C. Gordon
4d9e6e5f70 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.
2020-02-21 14:50:09 -05:00
Ryan C. Gordon
0a6d80abf7 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.
2020-02-12 13:08:29 -05:00
Sam Lantinga
fe8ce66b53 Attempt to make version detection safe for Mac OS X < 10.10 2020-02-11 10:35:14 -08:00
Sam Lantinga
52b410ab8e 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.
2020-02-11 10:21:31 -08:00
Sam Lantinga
c9c89783cb Miscellaneous pending fixes 2020-01-29 20:09:08 -08:00
Ryan C. Gordon
c7e1b289ee cocoa: Fix command line apps' menu bar not working on macOS Catalina.
Fixes Bugzilla #4937.
2020-01-27 17:15:12 -05:00
Sam Lantinga
a8780c6a28 Updated copyright date for 2020 2020-01-16 20:49:25 -08:00
Sam Lantinga
20daf54fd8 Added new HIDAPI driver files to the Xcode projects 2019-12-19 15:18:50 -08:00
Ryan C. Gordon
597f11e563 cocoa: Patched to compile on older compilers. 2019-12-05 17:27:06 -05:00
Ryan C. Gordon
ca2c8609e1 cocoa: SDL_GetDisplayDPI() should account for Retina displays.
Fixes Bugzilla #4856.
2019-12-04 12:20:24 -05:00
Sam Lantinga
7a3ae59037 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.
2019-12-03 07:12:55 -08:00
Alex Szpakowski
a963e36e2d macOS: more robust detection and switching of exclusive-fullscreen display modes (bug #4822). 2019-10-26 15:27:51 -03:00
Alex Szpakowski
59beaccd50 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.
2019-10-24 20:15:54 -03:00
Ryan C. Gordon
d5e378d198 cocoa: Implement SDL_WINDOW_ALWAYS_ON_TOP support (thanks, Gabriel!).
Fixes Bugzilla #4809.
2019-10-15 00:59:10 -04:00
Alex Szpakowski
074f6a512d 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). 2019-10-14 00:51:53 -03:00
Alex Szpakowski
009226c61e macOS: Fix non-highdpi OpenGL contexts not scaling properly in macOS 10.15 (bug 4810 and 4822). 2019-10-13 21:39:20 -03:00
Alex Szpakowski
f8bdefe1b5 macOS: Fix asserts in SDL_Render's metal scissor code when the window is resized. 2019-10-13 15:18:28 -03:00
Alex Szpakowski
1773da89f9 macOS: Fix a new issue in 10.15 where the window decorations don't always get restored after SDL_SetWindowFullscreen(window, 0). 2019-10-13 12:16:40 -03:00
Alex Szpakowski
dd29abb478 macOS: Use the proper type (NSSize instead of CGSize) for the bounds of metal views. 2019-08-22 19:23:52 -03:00
Alex Szpakowski
aebaa316c7 Add public APIs for creating a Metal view attached to an SDL window. Add SDL_metal.h. 2019-08-05 12:35:32 -03:00
Alex Szpakowski
f3683d3a09 macOS: fix a typo in touch handling code. 2019-08-04 23:30:55 -03:00
Sam Lantinga
63197c4338 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.
2019-08-02 17:19:50 -07:00
Alex Szpakowski
d5ec735a33 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.
2019-08-01 18:22:12 -03:00
Sam Lantinga
31cb854f98 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
2019-07-30 10:04:46 -07:00