View widget size policy

[dhardy]

Summary: the existing size policy for view widgets is poor and should be improved.

Status quo

ListView and MatrixView currently:

• Have an initial target number of columns/rows (5 for ListView, 3 × 5 for MatrixView)
• When first configured (before view widgets are allocated), allocate this target number of view widgets
• On initial update, assign data to these widgets from the first available entries
• In size_rules, calculate the per-child
  • minimum size from a default view widget (no data assignment)
  • ideal size from the maximum ideal size of a default widget and all assigned widgets
• In set_rect, calculate the view widget size (for all children) as the available size divided by the target number of columns/rows, clamping to the above minimum and ideal (max) values

Caveat: forcing all columns/rows to the same size is often not optimal. Is this too big a simplification?

Caveat: it is easy to encounter situations where later data items have a larger size requirement than the initially checked items (just run --example times-tables, increase the size and scroll). The above model does not adapt to handle this.

Suggestions

(Need expansion.)

Expand min & ideal child size

We can increase child_size_ideal and child_size_min as required for all currently-used data in update_widgets.

This, by itself, doesn't resize widgets until the next time the widget is resized (e.g. by resizing the window). We could however force this resize when required.

New caveat: sizes never reduce.

New caveat: column/row sizes change during scrolling which is visually jarring and messes with scroll offsets, though since sizes don't decrease it should stabilise quickly.

Recalculate min & ideal child size

As above, but recalculate child_size_ideal and child_size_min (allowing decrease in size).

New caveat: the solution is not guaranteed stable since decreasing the size allows more data entries to be represented which may then require an increase.

New caveat: column/row sizes change during scrolling which is visually jarring and messes with scroll offsets.

Per row/column/item sizes

Like other containers, calculate the size requirements for each column / row (by data index) separately.

New caveat: we can only estimate the size of the scrolled area, so scrollbars probably need fixes to handle frequent changes to the maximum scroll offset. Acceptable.

Unsolved: column/row size in MatrixView may depend on a large number of rows/columns which it will not always be practical to measure, therefore existing sizes may still change.

Resizable rows/columns

This really only applies to a TableView built over (or adapted from) MatrixView.

Use per row/column sizes (as above), but permit explicit resizing and don't auto-resize without a trigger. This is essentially what spreadsheets do.

(Aside: probably nearly all uses of MatrixView could benefit from row/column headers, so probably it should be adapted into a TableView with optional headers anyway.)