Display and UI¶

The interface is the reason the object is still worth carrying, so it is the part of Chikuma held to the strictest standard. Screens here are not drawn in code any more than they are on the device: the resource archive names the classes, the rows, the events and the destinations, and the code walks them. A screen that looks hand-built here is a bug.

From the panel up¶

The panel. The real LCD pipe is driven with the firmware's own configuration, including the panel tear-effect interrupt - the signal the panel raises when it is safe to hand it a new frame - and a second hardware window. That second window is what lets album art be composited under a hole in the main UI surface rather than painted into it: the two layers meet in the display hardware, not in software.

Granite, the compositor. Above the panel sits the firmware's compositor, which has its recovered name back: Granite. It owns six layer slots and one backend, chosen by kind: the LCD display pipe (six windows), or the hardware scaler. The scaler backend is recovered but deliberately not reproduced - nothing in this tree would call it, since Chikuma's scaler traffic comes straight from the video decoder. Granite paints from its own thread, the highest-priority thread on the device, which the panel tear-effect interrupt wakes rather than being driven from inside the interrupt or by whoever happened to draw last: the interrupt only acknowledges the panel and signals the thread, and the thread runs the pump. Granite's layers are exactly what earlier work in this tree had been calling display windows; recognising that the two are one thing did not rename anything, but it needed saying. A layer carries its own blend and alpha state, and the frame loop re-sends it from the layer's own bytes - one alpha write per frame, as the device does. See the device models for the panel and scaler hardware underneath.

Retained surfaces and transitions. A screen's regions - the menu, the status bar, the preview pane, the media list, Now Playing - each render into their own retained surface and are composed the way the firmware composes them. That is what makes the transitions real rather than approximated: a push slides a surface, and the fade family runs through a region's own alpha, instead of the whole screen being redrawn frame by frame.

The view classes¶

The view and controller class names are recovered from the image's own runtime type information, and their inheritance is recovered too. Views run:

TMsgHandler -> TResponder -> TView -> TCompositeView -> TListView -> TMenuView

and controllers run:

THistoryNode -> THistoryNodeSimple -> TController -> { TCntlrBasic, TSilverCntlr }

Recovery works up the chain: a subclass's behaviour is understood starting from its base's, which is why the work order follows the hierarchy rather than the alphabet. For each class, recovery means four things - its place in the vtable relative to its base, the geometry it computes (row heights, insets, how many items fit, how scrolling moves), the resources it reads, and the events it raises in the layout's own vocabulary. The per-class status of every one of them - recovered, a declared stand-in, or (an empty bucket now) invented - is tracked in chikuma/ui/COMPONENTS.md, which is required reading before touching any component.

Text is rendered through FreeType, taken from upstream at the version the image uses.

The controller stack: leaving is the operation¶

Screens live on a stack that the firmware calls its transition queue. A push starts the new controller immediately; a controller leaves by flagging itself and running the pump, which pops it and reveals the one beneath. This is why a screen's action handler often names no destination at all: leaving is the operation, and where you land is simply whatever was underneath.

Because of this, "the preview pane follows the highlighted row" is not something a component implements. It is the screen switching to another of its own layouts - the archive's event bindings carry a navigator verb that says so - where the layouts differ only in the canvases past the menu. Any component study that stops at geometry and resources misses where the behaviour actually lives; see the resource archive for how those bindings are read.

What is reproduced, and what is not¶

Working, each with a gate behind it: Home, Settings and Music; the media lists drilling Artists into Albums into Songs into Now Playing, with the aggregate "All Songs" / "All Albums" rows and the browse scope kept on the model the way the device keeps it; Cover Flow drawn on the CPU through the software OpenGL ES stack; the Genius path end to end; Playlists; several of the Extras apps (World Clock, Alarms, Sleep Timer, Stopwatch, Notes); localization in all twenty shipped languages; and the status bar and battery built from their own records.

Honestly open, and marked as such in Status: most push targets in the archive are still unserved; the preview pane does not yet follow a highlight below Home; Photos is read but not drawn; and a handful of the built Extras screens have stand-in depths. The status page is the live account; reports/ui_menu_worklist.md is the function-level worklist.