Back the data widgets with native NSTableView / GtkListView

[nicolas-maman]

Split out of #8, which asked for data widgets and is closed because they exist. This is the one clause of it that nothing implements.

What remains

Every data widget is composed from stacks and grids. Neither native collection view is referenced anywhere in the backends:

macOS  NSTableView refs:            0
gtk4   GtkListView / GtkColumnView: 0

vlist virtualizes by rendering a bounded, recycling window of rows over a stack. That is real virtualization (1000 items realize 10 widgets, asserted in tests/vlist_demo/spec_vlist_demo.ae) and it is enough for the scaling problem #8 described. It is not the same thing as a native collection view.

Why it is still worth doing

Native backing brings platform behaviour that a composed implementation has to reimplement one piece at a time:

• row reuse handled by the platform rather than by our window arithmetic
• accessibility integration as a real table rather than roles we set by hand
• keyboard navigation and type-select
• platform-native selection, focus ring and scrolling feel

Two of these have since been implemented by hand on the composed widgets: listbox keyboard navigation (Up/Down/Home/End) and table / columnheader / row accessibility roles across all three backends. That is worth knowing before starting, because it lowers the urgency and it means a native rewrite must preserve behaviour that now has specs asserting it.

Scope

Backing vlist and table with NSTableView on AppKit and GtkListView / GtkColumnView on GTK4, with a composed fallback on win32, while keeping the existing DSL surface and every current spec green. That last constraint is the hard part and the reason this is its own issue rather than a footnote on #8.

[nicolas-maman]

Status: the AppKit half is done and shipped in #90. vlist is backed by NSTableView there, virtualizing through the platform, with the vlist spec green on that leg.

GTK4 is not done. #91 attempted GtkListView and is closed unmerged because it realizes 205 rows for a window of 10, and that full instrumentation trail is recorded on the PR: what is settled (GTK4 does allocate headless; the viewport and adjustment are correctly wired at 240px with a real row height of 28), what was tried and ruled out (content-height pinning, a layout pump, unbind-vs-teardown cleanup, one-splice model building, demo sizing), and the one measurement that should come first next time (setup/bind/unbind counters).

Two things worth carrying forward regardless of how GTK4 lands:

• Native backing turns the DSL's window parameter into a real geometric claim. The composed path realizes its window by arithmetic and ignores geometry, so a list asked for ten rows in a window too short to hold them still "worked". A collection view cannot pretend that.
• The recycling cleanup hook is mandatory on both backends but for opposite reasons: AppKit's registry holds a strong reference, so skipping it leaks unboundedly; GTK4's holds a raw GtkWidget*, so skipping it dangles.

[nicolas-maman]

Correction to my earlier note, now that the instrumentation is done.

The GTK4 blocker has a precise diagnosis: GtkListView fixes its working set the first time the model is populated and never revisits it. Counters proved recycling works (bind and unbind both climb while scrolling) but the live set stays pinned at 206 rows for a window of ten, because the model is populated during window construction while the page size is still zero.

Everything I tried before finding that (content-height pinning, removing a layout pump, unbind-vs-teardown cleanup, one-splice model building, demo sizing) was downstream of that one ordering fact. Two attempts to fix the ordering itself then produced zero rows instead.

What remains is narrow and needs someone who can run GTK4 interactively: get the model populated after the viewport is real, probably from a map handler or a tick callback. Full trail in #91.

The AppKit half (#90) is done and green.

[nicolas-maman]

The GTK4 half was closed in #91 on a measurement I think was misread, and it is
worth correcting before anyone picks this up again.

#91 stopped because "the list still realizes 205 rows for a window of 10", and
concluded that GtkListView sizes its working set the first time the model is
populated and never revisits it, so the fix was to populate after the viewport
is real. Two attempts at that ordering then produced zero rows, and it stopped
there.

I reproduced the number in a 40-line standalone GtkListView program, with no
aether-ui involved, on GTK4 4.22.4:

rows=100    setup=100    page=240.0
rows=150    setup=150    page=240.0
rows=205    setup=205    page=240.0
rows=300    setup=205    page=240.0
rows=1000   setup=205    page=240.0
rows=5000   setup=205    page=240.0
rows=20000  setup=205    page=240.0

and against viewport height, with 1000 rows throughout:

win_h=100   page=100.0   visible=5.3    setup=205
win_h=240   page=240.0   visible=12.6   setup=205
win_h=600   page=600.0   visible=31.6   setup=205

setup is min(N, 205). It does not track the viewport and it does not
track the model. 205 is a fixed pool GtkListView keeps, and the identical number
CI reported (live=205/206) is that pool, not a working set sized against a zero
page size.

Two things follow.

GtkListView was virtualizing correctly the whole time. 20,000 rows realize
205 widgets, which is 1%. The viewport was fine too: my probe reads
page=240.0, list_h=240, sw_h=240 with the model filled before present, the
exact order #91 believed was the bug.

The acceptance criterion cannot be met by GtkListView. vlist's composed
path realizes ~10 widgets for a 10-row window because it does its own window
arithmetic, and NSTableView genuinely realizes only visible rows, so #90 could
assert that. GtkListView will not go below its pool for any viewport, so a spec
mirroring #90's numbers fails against a correct implementation. That is what
#91 was chasing.

So the next attempt should not try to make GTK4 realize ten rows. It should
assert what actually distinguishes native backing from the composed path:
that the widget count stops growing with the model (205 at 1,000 and at 20,000),
that recycling happens (bind and unbind climb while the live set does not, which
#91's own counters already showed), and that rows the driver can see are correct
after scrolling.

I have not reopened the implementation. #91's branch may well be sound as
written, and it would need re-testing against a criterion GtkListView can
satisfy rather than against #90's.