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.
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.
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.
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.
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)
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
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.
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.
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.
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 688c4a90d9/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;
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.
On Mojave, this will report large numbers for retina displays in fullscreen
mode, which isn't how it works on previous versions.
(transplanted from c6c1731780e2bef94f944a4795e2dfbba46d9500)
