When allocating space for a cell colspan > 1, preferentially
allocate space to columns that have no colspan = 1 cells. If you
have content like this (content padded to 10 and 20 chars to make
calculations easier):
[[(2, "longer content567890"), "shorter890"],
["shorter890", (2, "longer content567890")]]
Taking only colspan = 1 cells into account, the widths of the
columns are (10, 0, 10).
To fit the first longer content in, the current algorithm expands
the first two columns equally, so the widths become (15, 5, 10).
Then to fit the second longer content in, the second two columns
are widened equally (or nearly so), resulting in final widths
of (15, 8, 12) and a table layout like this:
+-------------------------+--------------+
| longer content567890 | shorter890 |
+-----------------+-------+--------------+
| shorter890 | longer content567890 |
+-----------------+----------------------+
which is bizarrely asymmetrical given the input and wider than it
needs to be.
If instead we preferentially widen columns that have no width
from colspan = 1 columns, we get this layout:
+----------------------+------------+
| longer content567890 | shorter890 |
+------------+---------+------------+
| shorter890 | longer content567890 |
+------------+----------------------+
Which is much more in line with my expectations.
Mark all devices with DHCP enabled as pending when the config is
applied, and mark them as timed out ten seconds later if they have not
received any addresses.
The visible impact of this is that the addresses for a NIC are now
displayed underneath its name and a long "info line" (i.e. mac / model /
vendor) for a nic no longer distorts its table.
This lays the groundwork for better handling of NICs that fail to dhcp
and things like that.
The main thrust of this is to not create virtual interfaces until
applying the config.
This meant that the network model has to change a bit to be able to
represent interfaces that do not yet exist on the system. I did this
by ripping out most of the existing network device code: now a
NetworkDev is really just a wrapper for the config for a device and (if
it exists) the netlink data too. A few places had to adjust to checking
if the netlink info is available before accessing it but all in all it
was not that painful.
There are a few other refactorings in this commit that perhaps should be
split out (how the bond parameters are handled, some stuff about
resizing the table rows when interfaces are edited) but it doesn't
really seem worth it.
Michael Hudson-Doyle