Cocoa: Finish launching NSApp in glfwInit

This moves the remaining bits of NSApplication initialization into
_glfwPlatformInit.  As a side-effect of this, any command-line program
initializing GLFW will get a menu bar, which is not ideal.

If this has happened to you and a bisect led you here, please see the
GLFW_COCOA_MENUBAR init hint introduced in GLFW 3.3.

If this patch is a terrible idea, please get in touch in the 3.4 release
timeframe.

This is a replacement for 6e6805000a,
which attempts to preserve the existing menu bar creation behavior for
the 3.3-stable branch.

Fixes #1649.
This commit is contained in:
Camilla Löwy
2020-03-05 20:32:19 +01:00
parent 6aca3e99f0
commit 72366ac9a9
9 changed files with 32 additions and 34 deletions
-15
View File
@@ -884,9 +884,6 @@ int _glfwPlatformCreateWindow(_GLFWwindow* window,
{
@autoreleasepool {
if (!_glfw.ns.finishedLaunching)
[NSApp run];
if (!createNativeWindow(window, wndconfig, fbconfig))
return GLFW_FALSE;
@@ -1377,9 +1374,6 @@ void _glfwPlatformPollEvents(void)
{
@autoreleasepool {
if (!_glfw.ns.finishedLaunching)
[NSApp run];
for (;;)
{
NSEvent* event = [NSApp nextEventMatchingMask:NSEventMaskAny
@@ -1399,9 +1393,6 @@ void _glfwPlatformWaitEvents(void)
{
@autoreleasepool {
if (!_glfw.ns.finishedLaunching)
[NSApp run];
// I wanted to pass NO to dequeue:, and rely on PollEvents to
// dequeue and send. For reasons not at all clear to me, passing
// NO to dequeue: causes this method never to return.
@@ -1420,9 +1411,6 @@ void _glfwPlatformWaitEventsTimeout(double timeout)
{
@autoreleasepool {
if (!_glfw.ns.finishedLaunching)
[NSApp run];
NSDate* date = [NSDate dateWithTimeIntervalSinceNow:timeout];
NSEvent* event = [NSApp nextEventMatchingMask:NSEventMaskAny
untilDate:date
@@ -1440,9 +1428,6 @@ void _glfwPlatformPostEmptyEvent(void)
{
@autoreleasepool {
if (!_glfw.ns.finishedLaunching)
[NSApp run];
NSEvent* event = [NSEvent otherEventWithType:NSEventTypeApplicationDefined
location:NSMakePoint(0, 0)
modifierFlags:0