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.
before this, if you press up on e.g. the network view, focus would go to the first nic
not the last as you might expect. this is pretty obscure but oh well. such is urwid.
Create palette for traffic light buttons: green (default), amber and
red. Color-code most buttons.
Make all progressbars orange for the completed part.
1) move the done / cancel buttons (and error display) out of scrolling region
2) focus done by default
3) update footer texts to make sense
4) use a bit more of the horizontal space to show interface information
The main change here is to separate the state a network device is in and the
state we want it to be in. So it now parses the netplan config on a system as
well as probing the state of via probert.
The UI is changed to make this distintion too, and be IMO a bit more
consistent. Somewhere in this I've removed the display of whether the
probed address was found via DHCP or not, possibly that should be put
back if it doesn't make things too cluttered.
In dry-run mode, we now still write the config and feed it to netplan, but
in a way that doesn't affect the system we are running it on.