vcl: osx: clean up macOS nested ImplSVMain() hacksHEADmaster

LO on macOS must run NSApplicationMain() to enable non-blocking JVM
native windowing, as the JVM runs NSApplicationMain() itself if the
callstack isn't already running it. NSApplicationMain() sets up the
Cocoa application, loads the NIB, and eventually runs the event
loop, returning only when the application exits.

If the JVM runs NSApplicationMain(), this blocks the macOS VCL
event loop because NSApplicationMain() grabs all the events
and doesn't return. Because of this, the macOS VCL must run
NSApplicationMain() itself early in startup, which will prevent the
JVM from running it later.

Previously the JVM issue was worked around by running
NSApplicationMain() from early in ImplSVMain(), returning half-way
through, and eventually re-entering ImplSVMain() using condition
variables to only execute the second half on re-entrance. This was
confusing.

Instead, break ImplSVMain() into two parts and allow VCL plugins
to override the second part that actually runs the application.
On macOS instead of re-entering ImplSVMain() after LO has loaded
call the simplified second part of ImplSVMain().

[side-note: the original commit introducing the nested ImplSVMain()
hack (284a7f60fff72c4d8c011ff60ea2e40163cd25c3) mentions running
the JVM in a thread to get around the blocking event loop issue;
but this doesn't work because even if the JVM is loaded and created
in a separate thread, it calls NSApplicationMain() from the main
thread anyway. It must do this because on macOS all UI-related work
must happen from the main thread as Cocoa is not fully re-entrant.]

Change-Id: I2adfef32502b8ad0efaf16d6959df16d937019df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200714
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>

0 files changed, 0 insertions, 0 deletions