core, platform, ui

The libraries

Three C++ libraries in a strict layered line, each its own repository, each buildable and testable alone. Core holds the model and knows nothing of a screen. Platform owns the OS, the GPU, and the transport. UI draws.

Three libraries, one line

Kinogaki is three C++ libraries stacked in a strict line. Each is its own git repository, builds with its own build.sh (clang++, C++20, no CMake required), and self-tests with test.sh.

Kinogaki UI         widgets, GPU drawing, the view reconciler        ~7,100 lines
   │
Kinogaki Platform   window, input, Metal RHI, buses, SDUI transport  ~2,400 lines
   │
Kinogaki Core       the document model, codecs, the C ABI            ~9,900 lines

The dependency arrow points down: ui needs platform and core; platform needs core; core needs nothing. Nothing points back up. Core has no idea a screen, a socket, or an operating system exists. That rule is enforced, not aspirational: it is what lets Core stay portable and lets every layer be tested in isolation.

Kinogaki Core: the model

Kinogaki Core is the substrate from the model: typed Elements at Paths, Properties over time, Connections, composition by reference, the evaluator, the .prisma and .prism serializers, and the JSON / Markdown / HTML / SVG codecs. It also exposes the C ABI (<kinogaki/C.h>), the foreign-language seam any binding drives the model through. Pure, dependency-free C++. A tool that only needs to read or edit a Document needs only this library.

Kinogaki Platform: the runtime

Kinogaki Platform is the native layer between the OS and the application:

• The OS boundary. ISystem, IWindow, IContext behind clean interfaces, plus a pull-based event loop, 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, normalizing every platform quirk to one shape.
• The RHI. A backend-abstract render hardware interface (devices, command buffers, buffers, textures, shaders, pipeline state, on-window and offscreen passes) modeled on Metal but not bound to it.
• The buses. A message bus and a generic command bus, the domain-agnostic plumbing an application edits its Document through.
• The server-driven-UI transport. The protocol engine SduiChannel, the WebSocket framing kinogaki::ws, and the browser client SduiClient. This is the home of the loop and the wire.

Platform is what a Python app binds to run on a device, and what the server uses to push views over a socket. All the operating-system glue lives here and only here (see platforms).

Kinogaki UI: the view

Kinogaki UI is a GPU-drawn, retained-mode widget toolkit. It builds a widget tree from a view-Document and reconciles updates in place: a value change mutates the existing widget (so scroll and focus survive), a structural change rebuilds while reusing every widget whose Path and type held. One render path, WidgetView::setView, drives both faces; the only thing that differs between the desktop and the browser is the backend beneath it.

The software around the libraries

The libraries are the floor. The products built on them:

• CLI (kinogaki): check / convert / pack / unpack for files, plus init / serve / run for projects.
• Server: the bridge, serving a live Document over a typed-operation protocol (MCP-facing).
• Editor: the GUI app on platform + ui + core.
• Site renderer: .prisma Document to HTML; powers every docs site, including this one.
• Python: pip install kinogaki, a ctypes binding over the C ABI (see the Python boundary).

Naming, so it stays straight

The library and platform are Kinogaki: namespace kinogaki::, C ABI kinogaki_*, includes under kinogaki/, packages named kinogaki. Prism is the file format only: .prisma (text), .prism (binary), #prisma (header). The model is Kinogaki; the file it writes is Prism. They stay distinct everywhere, in code and in prose.