urwid doesn't know about the _select_first/last_selectable methods our
containers use to make tab-cycling work so its WidgetWrap doesn't
forward them along. So add a WidgetWrap that does, and use it in the one
place that it matters so far (more coming soon!).
for all the usual reasons why composition is better than inheritance,
but in particular because I want to have a listbox that has a scrollbar
but not our custom tab behaviour in another branch. decoration in urwid
is not as transparent as it sometimes seems it should be but luckily
there's only one view that does much with its listbox and it was due
for some cleanup anyway.
Before this change, subiquity has lots of ListBoxes that just contain a single
Pile containing all their contents. This is (a) a bit silly (b) make some parts
of the scrolling experience a bit poor, for example urwid tries to scroll all
of a ListBox element into view when it gets focus but this is defeated by
shoving all the elements into a Pile (this causes
https://bugs.launchpad.net/subiquity/+bug/1750058 and a few other strange
bits).
The fix for this is obvious (don't wrap ListBox elements in a Pile) but this
breaks some aspects of tab cycling (when you shift tab back into a listbox you
want the last element of the box to be both selected and scrolled into view,
that sort of thing). Fixing all these bits of broken behaviour required
rewriting the tab cycling implementation to the point of copy/paste/hack-ing
the Pile.keypress method. Rather than doing the same for Columns, I just
prevent the creation of Columns with more than 1 selectable, which as we want
subiquity to be navigable with up/down/return does not seem so bad.
As penitence for all this, I've added a bunch of commentary explaining what is
going on.
Michael Hudson-Doyle