[Development] A new approach for Qt main()

[Edward Welbourne]

Morten Sorvig supplied:

> For some background, here’s what typical application startup looks
> like on macOS, NaCl, and Emscripten:

I've updated [0] to illustrate these.
[0] https://wiki.qt.io/Application_Start-up_Patterns

> macOS: Define the application delegate, create instance of it in main()
>
>  // Define application delegate with app lifecycle callbacks
>  @interface AppDelegate ()
>  @end
>
>   @implementation AppDelegate
>   - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>      // Init application here
>   }
>
>   - (void)applicationWillTerminate:(NSNotification *)aNotification {
>      // Tear down here
>   }
>   @end

Please say more about what has to happen in these, especially init;
presumably, we need to add some handlers to something like an event
queue, to ensure our application gets told what's happening and when to
respond to it.

>   // In main, install application delegate and start the app
>   int main(int argc, const char *argv[])
>   {
>        NSApplication *app = [NSApplication sharedApplication];
>        app.delegate = [[AppDelegate alloc] initWithArgc:argc argv:argv];
>        return NSApplicationMain(argc, argv);
>   }

I take it NSApplicationMain(argc, argv) contains a system standard event
loop that looks to the shared NSApplication for its control.

> Native Client: Define pp::CreateModule() and return the application
> module (which is a subclass of pp::Module)
>
>   namespace pp {
>     Module* CreateModule() {
>        return new ApplicationModule();
>     }
>   }

I need some clue what methods pp::Module allows us to override and how
we can, by doing so, control what the resulting app does.

> Emscripten: implement main()
>
>   int main(int argc, const char *argv[) {
>      // Init application here
>      return 0;
>   }
>
> main() should/must return to keep the web page responsive.

I take it, then, that "main()" isn't the whole program, in the classic C
way, just an insertion into an existing running something - into which
we presumably inject some application-specific objects that connect
themselves into the event stream and provide ways to respond.

> There is API for simulating a main that does not return and preserve
> the stack, see emscripten_set_main_loop() in the emscripten
> documentation.

Sounds complicated.  Better to fit in naturally with the native system's
preferred modus operandi.

Illustrations (maybe provided by link to existing examples) of how we
presently shoe-horn our existing architecture into the various cases
would be a passable first attempt at answering the open questions ...

	Eddy.