Sizing view widgets and scrolling

[dhardy]

ListView and MatrixView have a problem: they may have many children and cannot practically instantiate and find the size requirements of each, yet (at least for the purpose of calculating scrollbar size/position) must calculate the size requirements of everything.

Assumption: each item should be allocated the same size. This is assumed, though we might not always want this.

The current model, since #282 (with some tweaks since):

• initially, allocate enough widgets to cover the ideal number of rows and columns
• construct a default widget (without data) and use that to determine the minimum item size
• calculate item SizeRules as the maximum over whichever widgets are available
• multiply item rules by the ideal number of rows/columns and use for view size requirements
• allocate an item size based on the available size divided by the ideal number of rows/columns, clamped to be no smaller than the minimum item size (from default widget) and no larger than the ideal item size (from max of widgets available when size_rules was called)

The result vaguely works, but is not ideal. How to improve?

Possibly we should:

• revise scrollbar behaviour to only require an estimate of the scrollable area
• use the above logic to estimate area
• calculate size and offset of each visible item based only on its own requirements (no general size), keeping track of the offset for the first visible item

Problem: if someone tries to jump to the middle of the estimated scrollable range, we need to calculate the position of everything that came before it first?

Problem (matrix): we need to align items in columns and rows. By itself this is okay (just remember the offset for each visited row/column), but combined with the scroll-jumping problem it may be problematic.

[dhardy]

Assumption: each item should be allocated the same size. This is assumed, though we might not always want this.

examples/times-tables demonstrates a problem here: increasing the range to obtain 4-digit numbers results in the view only showing the last three digits in each case. What should be the solution here?

• In this specific case, clearly no cell is larger than the last (bottom-right) one (at least with monospace font). MatrixView does not know this, and in the interests of scalability it cannot test all cells, but the UI designer could hint that this cell should be used to determine cell size.
• Potentially MatrixView could evaluate the cell size to be the largest cell currently loaded, increasing (and possibly also decreasing) this as the viewed cells change. This complicates the scrolling model but not too much. It will result in visual glitches whenever the cell size changes.
• As above, but individually for each visible row and column. The scrolling model becomes much more complex but the visual glitches (and overall appearance) should be better.
• Perhaps the UI designer should have more control, e.g. via a callback to get the cell size for a row or column? This would allow traditional spread-sheet design where columns are allocated a fixed-size unless manually resized. It should still allow responsive designs as above.

The last option above appears the best, but leaves the question of how the scroll-model should work unsolved: (1) current scroll offset will probably have to be a combination of the first row & column key plus (optionally) a visual offset, while (2) calculating the total size of the scrollable area (or scrollbar position and size) is hard. Possibly the UI designer should also be responsible for providing the scroll-bar position and size.