System, window & context

Three interfaces

Platform presents the operating system through a small set of interfaces, so nothing above it names Cocoa:

ISystem — the process-level boundary: create windows, pump and pull events, timers, cursor, clipboard (setClipboardText), native open/save file dialogs, and wakeup() to nudge the loop from another thread.
IWindow — one window: title, size (points) and backing pixel size, its drawable context, close requests.
IContext — the per-window drawable: acquire the frame and present it (the RHI owns the command buffer in between).

auto sys    = createSystem();
auto window = sys->createWindow("Editor", 1200, 800);
auto ctx    = window->context();
auto path   = sys->openFileDialog("Open", {"prisma", "prism"});   // native chooser
sys->setClipboardText(selection);

The pull-based event loop

Input is pulled, not pushed through callbacks. The backend translates native events into one flat Event struct and queues them; the app asks the OS to pump and then drains the queue:

sys->processEvents(timeoutSeconds);   // <0 block until an event · 0 poll · >0 wait up to t
for (Event e; sys->nextEvent(e); ) { /* handle e */ }

The timeout is the load-bearing detail. Block (<0) and the app sleeps with zero CPU until the OS delivers an event — instant wake, no spin. Poll (0) to interleave with other work. Tick (>0) to drive a timer (a progressive render's progress, say) without a busy loop. This is the primitive Prism UI's idle-cheap app loop is built on, and it is also why a worker thread calls wakeup() — to post an event that breaks a blocking processEvents so a finished job shows up promptly.

One flat Event

An Event is a plain, trivially-copyable POD with a type and the fields valid for that type — pointer position and button, scroll delta, key and codepoint, window size. Keeping it a flat struct (rather than a class hierarchy) makes the queue trivially copyable and the consuming switch simple. The synthesized intent (value, pressPos) rides on the same struct.

Timers, cursor, clipboard, dialogs

The incidental-but-essential OS services live on ISystem too, normalized to one shape across platforms: set the cursor, read and write the clipboard, run a native modal file chooser, schedule a timer. Because they are on the interface, the UI toolkit and the Editor use them without a single #if __APPLE__ — and a future backend supplies them the same way. The events these produce are covered next, in the event model.

‹ Quickstart The event model ›