At the core of panelreel (see #4) is the ability to arrange tablets in a finite panel. The proper arrangement is deterministic and unique for a given
number of lines in reel
order of tablets
number of lines in those tablets
scrolling configuration
focused tablet, and
known, valid first line of that tablet
For any catastrophic event (say resizing of the reel), we can work out the new reel by starting with the focused tablet, drawing it, placing it, and then working backwards and forwards until the reel is full (the only question here is an unfilled reel, in which case everything might need be translated through the reel's plane).
Discovering the number of lines requires either:
knowing the maximum number of lines each tablet can draw, and forcing each tablet to call into the panelreel to report a change, or
demanding each tablet provide the number of lines it can draw on demand via outcurses callback, followed by an optional draw, or
allowing each tablet to redraw itself based off a callback from outcurses
The third option seems superior. Both option 1 and 2 have a fundamental race, where outcurses thinks a tablet can generate some number of lines, but that value has changed by the time outcurses wants to redraw the tablet. This invalidates whatever assumptions outcurses might be leveraging based off its knowledge.
Instead, when moving tablets around, we call into one with:
a maximum number of lines that could be of use (optimization, not correctness), and
whether we need toplines or bottomlines
The callback then draws all it wants, and we take what's useful to us. The only problem is that it might require more redraws than is necessary, since we can't say "this tablet is unchanged; leave what it has there" from outcurses. So long as we ensure the client can do its own quick-validation, though (basically don't destroy or clear the previous panel), we do no extra work.
At the core of panelreel (see #4) is the ability to arrange tablets in a finite panel. The proper arrangement is deterministic and unique for a given
For any catastrophic event (say resizing of the reel), we can work out the new reel by starting with the focused tablet, drawing it, placing it, and then working backwards and forwards until the reel is full (the only question here is an unfilled reel, in which case everything might need be translated through the reel's plane).
Discovering the number of lines requires either:
The third option seems superior. Both option 1 and 2 have a fundamental race, where outcurses thinks a tablet can generate some number of lines, but that value has changed by the time outcurses wants to redraw the tablet. This invalidates whatever assumptions outcurses might be leveraging based off its knowledge.
Instead, when moving tablets around, we call into one with:
The callback then draws all it wants, and we take what's useful to us. The only problem is that it might require more redraws than is necessary, since we can't say "this tablet is unchanged; leave what it has there" from outcurses. So long as we ensure the client can do its own quick-validation, though (basically don't destroy or clear the previous panel), we do no extra work.