Window · input · GPU · buses

Kinogaki Platform

The native runtime layer of kinogaki: OS windowing and input behind clean interfaces, a backend-abstract Metal render hardware interface, a synthesized event-value model, and the message and command buses an application edits its Document through.

The runtime beneath a native app

Kinogaki Platform is the layer between the operating system and your application: window and input abstraction, a Metal render hardware interface (RHI), and the message and command buses that carry events and edits. Kinogaki UI is built on it, and it runs on its own: a renderer or a game hosts it directly and draws its own frames.

It is the native half of Kinogaki. All the operating-system and GPU glue lives here (the Objective-C++ to Cocoa and Metal), so that everything above it, and Kinogaki Core beside it, stays clean, portable C++ and Python.

What's in it

The OS boundary: ISystem / IWindow / IContext and a pull-based event loop, plus timers, cursor, clipboard and native file dialogs.
The event model: a flat Event struct and an EventSynth that turns raw input into Press / Release / Click / DoubleClick / Drag intent, with all platform quirks normalized to one shape.
The RHI: a backend-abstract GPU service covering devices, command buffers, buffers, textures, shaders, pipeline state, and offscreen/on-window passes.
The buses: a Message Bus and a generic Command Bus, the domain-agnostic plumbing an application edits its document through.

Where it sits in the stack

Kinogaki UI         widgets, GPU drawing  (built on Platform)
   │
Kinogaki Platform   window · input · Metal RHI · buses   ← you are here
   │
the OS           Cocoa / Metal  (the only non-portable code in Kinogaki)

Build on Platform directly for a custom rendering application, or build on Kinogaki UI for a full widget interface. Either way Kinogaki Core rides alongside, untouched by any of it, holding the document.

Why it's a separate library

Isolating the platform layer is what lets the rest of Kinogaki stay portable and testable. The document model has no idea an operating system exists; the UI toolkit talks to an abstract RHI, not Metal. When a Windows or Linux backend lands, it implements these same interfaces and nothing above changes. Start with the Quickstart to open a window, or read the event model for the input the widgets depend on.

Quickstart ›