The shared bootstrap for a standalone (non-node-hosted) GUI app (§SAL-1, §SAA-1.6). More...
| Header: | #include <StandaloneHarness> |
Every dual-hosted app used to hand-roll the same startup sequence in its runGui(): organization/application naming, QApplication, style, window icon, window-title suffix, config root, configure-before-show and the first-show splash. The harness owns that sequence once, so each app's runGui() collapses to constructing its shell inside a callback and handing it here.
The sequence (in order):
1. Organization/domain/application naming (Constants). 2. QApplication — created only if none exists yet, so a test (which already runs under a QApplication) can drive the harness directly. 3. CLI parsing via the node-free AppCommandLineParser and an AppContext over it (the ZooMain pattern, §SAB-1) — --base-dir roots <baseDir>/settings.ini and every derived path. 4. AppStyle / StyleManager with the app's accent color; window icon. 5. A StandaloneActivityContext (the Light provider) with the settings facility pre-registered; the app registers the rest. 6. prepare(): the app's callback builds and **configures** its shell (§RH-B: configure BEFORE show() — a deferred configure left the backing store raster and the RHI viewport blank), then the harness titles, shows and — when requested — splashes it. 7. exec(): the event loop; on exit the shell is hidden, not deleted (destroying a window crashes on Wayland+Vulkan while the VkSurfaceKHR is still referenced; process exit does final cleanup).
Facilities are injected into the shell by the app's callback via the shell's existing setters, sourced from context() (§SA-4 D10).
See also StandaloneActivityContext and AppContext.