Readiness is a sequence

A Gameface feature crosses several owners. Reaching one stage does not imply that the next stage is ready.

  1. The Python feature owner is active in the correct account or arena context.
  2. The current Wulf parent and window exist.
  3. The Gameface engine bridge is ready.
  4. The HTML document and JavaScript entry have loaded.
  5. The DOM root and required native nodes exist.
  6. The intended root or child view model is available.
  7. Initial model data has been rendered and later subscriptions are installed.
  8. Layout has produced a positive width and height.
  9. The active lobby route or battle page permits the feature to be visible.

Use the signal owned by each boundary. When no dependable event exists, use a bounded retry tied to the current context generation. Stop on success, context change, teardown, or deadline; never leave an infinite readiness poll running.

App space versus window readiness

App-loader events, GUI-space transitions, Wulf window status, browser load, DOM readiness, and route visibility are different boundaries. A namespace reaching initialized state does not prove that a particular main window, shared page, route, model, or standalone overlay parent is ready.

  • Check app state in the namespace that owns the feature; a lobby app state does not prove a battle app or battle page is usable.
  • Use GUI-space leave/enter events for high-level context changes, then wait for the specific view or window owner required by the overlay.
  • Treat Wulf status notifications as window-ID events. Re-resolve the window from the window manager instead of retaining an old Python window reference.
  • For standalone overlays, select the account or avatar context, wait for the page boundary, resolve the current main window, require a live proxy and loaded status, then construct the owned window.

Read by topic

Choose a focused chapter. Complete examples and reference details are preserved on their topic pages.