A custom node-graph UI was pulling me toward a bigger question: could the small Linux services under it become a reusable foundation? I named that piece Whacky Platform Layer and kept it in C, with Linux as the first target. That separation mattered because a window and input layer should not quietly grow into the graph engine or the game’s production rules.
The work proceeded through narrow contracts for windows, input, drawing, files, and replay. Small helpers made the layer useful, while reported CTest and CI results gave feedback on particular revisions. Later, I corrected a roadmap that treated already-present code as if it were still waiting to be built. That is a different kind of progress check from a green test: the plan itself had to match the repository. This history stays with explicit WPL work and leaves unrelated GUI wrapper and archive-game messages with their own projects.
What belonged in the layer
The C11 brief covered X11 windowing, input snapshots, timing, draw-command buffers, software rendering, canvas math, a debug overlay, file I/O, and replay. Its public API was to remain C-compatible and free of backend-specific types.
That made the separation concrete:
| Layer | Responsibility |
|---|---|
| Platform | Window, input, timing, drawing submission, file and replay services |
| Higher-level UI/graph code | Node-graph behavior and tool interactions |
| Game | Production rules and gameplay meaning |
The initial brief excluded a GUI-widget system, game logic, graph logic, SDL support, other operating systems, and a general GPU abstraction. A draw primitive could help a later tool draw a panel without making the platform layer responsible for what that panel meant.
Small additions made the boundary useful
The historical commit output records a sequence of practical helpers: ASCII text metrics and limits, atomic file writes, polylines, dashed lines, cursor shapes, a clip-rectangle stack, custom debug-overlay lines, and panel/rounded-rectangle primitives.
A local CTest report after the cursor work explicitly showed 12 of 12 tests passed. The named checks covered input state, draw lists, text metrics, canvas behavior, debug overlay, file I/O, replay format, replay behavior, logging, the window API, and public-header compatibility from both C and C++.
That report is stronger than a statement that the library merely compiled, but it remains a report from that development session. It does not by itself establish every graphical behavior or the state of a later branch.
Contracts became part of the implementation work
The later Linux-only upgrade work moved to a separate development branch. It touched backend boundaries, window ownership, renderer behavior, and API contracts, so the branch gave those related changes a place to integrate without treating every intermediate state as the main baseline.
A substantial portion of the work made existing behavior explicit. The file-I/O contract covered whole-file reads and writes, the atomic sibling-temporary-file-and-rename path, size limits, empty files, data ownership, and cleanup expectations. It also stated what the layer did not own: an asset pipeline, project format, virtual filesystem, or editor autosave policy.
The replay contract was similarly narrow. It described input-snapshot replay, opaque recorder/player handles, finite input and frame-delta requirements, binary-format validation, and saving through the file-I/O layer. Loading malformed data should fail without destroying a previously valid replay.
That was not a promise to replay an entire editor or game. Raw X11 events, graph state, application state, renderer capture, and project serialization sat outside that replay boundary.
The roadmap had to match the code already present
One review caught a planning error worth preserving. A later phase still listed the private backend vtable, dispatcher, and X11 dispatch wiring as future work even though the baseline already contained them. The correction was to start subsequent planning from ownership cleanup and multi-window work rather than duplicate an abstraction that already existed.
This is a small example of why the documents mattered. A roadmap that describes completed work as missing can cause as much confusion as an unclear API. The useful next step depends on knowing which responsibilities already have an owner.
The historical code and tests made the Linux C layer more than a drawing-board idea. The roadmap correction mattered too: the next increment had to start from what the repository already contained. I kept the unrelated archive and game GUI work with their own projects instead of counting it as a WPL result.