Hub UI Slices Should Prove OS Boundaries

Context

The first Prometeu Hub visual slice introduced a retro/minimalist Home surface with two fake native Shell apps, ShellA and ShellB. The visible work was small by design: two launch buttons, simple green/blue app windows, mouse click activation, and a close affordance.

The important result was not only the look. The slice proved that a system UI can become more visual without taking ownership away from SystemOS and Firmware.

Key Lessons

Keep visual intent separate from OS effects

The Hub now emits explicit system-profile actions for user intent. Launching a Shell app is represented as an action; Firmware/SystemOS creates the native Shell task, process, and task-owned window.

This preserves the useful split:

Hub renders and navigates
Hub emits intent
Firmware/SystemOS executes lifecycle, task, process, and window ownership

That split is more important than the exact shape of the first UI.

A small visual slice can validate lifecycle

The implementation deliberately avoided a generic catalog, toolkit, tabs, footer bar, and controller navigation. Even with that narrow scope, it proved the critical flow:

Hub/Home -> ShellA or ShellB -> task-owned window -> close -> lifecycle close -> Hub/Home

This is the right kind of first UI milestone: it exercises the OS model instead of only drawing a mock screen.

Existing input may be enough for the first cut

The desktop host already maps pointer state into the runtime touch bridge. The Hub slice reused that path for mouse/click hit testing instead of inventing a new input system.

The result is intentionally simple: button rectangles in 270p space, click-edge activation, and a close hit target. Controller focus can build on this later, but it does not need to be solved before the Shell lifecycle flow is proven.

Font assets are not the same as font integration

Pixel Operator is present as TrueType assets under assets/pixel-operator/, but the current runtime text path is a built-in bitmap glyph renderer exposed through GfxBridge::draw_text.

Deferring TrueType integration was correct because adding a TTF loader, font manager, rasterizer, or public font contract would have expanded the UI slice into unrelated architecture. The existing bitmap text remains compatible with the retro direction until a dedicated font decision exists.

Pitfalls

Do not let visual components call task/process managers directly.
Do not treat window removal as app close; Shell app close must go through lifecycle.
Do not turn the first two buttons into a generic app catalog by accident.
Do not introduce a broad UI toolkit before multiple real Hub surfaces need shared components.
Do not interpret the Pixel Operator asset as a completed font system.

Evidence

The implementation evidence for this slice was:

cargo test -p prometeu-system: 83 passed.
cargo test -p prometeu-firmware: 17 passed.
cargo test -p prometeu-host-desktop-winit: 25 passed, 5 ignored.
discussion validate: passed.

The firmware tests cover launching Shell apps through Hub actions, creating task-owned windows, and closing through lifecycle back to Hub. The system tests cover local hit testing and layout/action coupling for the Hub slice.

References

DEC-0028 - Prometeu Hub Initial Retro Shell UI Slice.
PLN-0062 - Native Shell Launch and Lifecycle Wiring.
PLN-0063 - Hub Mouse Input and Click Routing.
PLN-0064 - Retro Hub Home and Fake Shell UI.
PLN-0065 - Pixel Operator Font Integration.
PLN-0066 - Hub UI Slice Validation and Lesson.

3.8 KiB Raw Blame History