Hi everyone.
Some of us had an impromptu meeting around the text-installer and
text-mode Device Driver Utility (DDU) invocation and interaction. After
the meeting I followed up with Frank, our resident UI expert. Here's a
summary of what I discussed with Frank, along with enough background for
those who didn't attend.
1)The text mode comes up with a menu of four options: Run DDU, run
installer, shell and reboot. We discussed just dropping to the shell
automatically if the installer exits after a successful installation,
and rebooting when the user quit that shell. Frank thought that
automatically dropping to a shell after the text installer finished
successfully was not worth the effort. He felt that displaying a menu
with four choices was fine. (I didn't solicit this particular response
either :) )
2) We discussed what the DDU should do about configuring network access
so it can go to repos, etc. We discussed the idea of having a library
for displaying the network screens and doing the network setup; this
library would be linked by both the DDU and the installer. We discussed
what to do in the installer if the DDU has already set up the network.
There were three choices in the first network screen, per Frank's
original mock up: auto, manual, none. One option discussed was to offer
a fourth choice alongside the existing three: to keep the network as set
up by the DDU (with the settings displayed, of course).
Frank's preference for what to do in the installer regarding network
setup, after the DDU has configured the network, is to still offer only
three choices in the first network screen. If DHCP wasn't used to set
up the network, display the manual screen with all fields filled in when
chosen. The user could then change or tweak accordingly. The choice
for keeping three choices boils down to having a less
cluttered/confusing screen at the expense of having the user hit an
extra screen.
On a related note, it would be better not to pass configuration from the
DDU to the text installer, but to have the text installer pick it up
using ifconfig and other commands (vs passing a file). Not only is this
kludge-free, but it allows the user to tweak the network settings
post-DDU and pre-Installer and have those new network settings be
properly reflected in the Installer network screens.
3) Frank and I agreed that there should be a common library of network
setup / screens to be shared by the DDU and installer. Not only does
this provide a more consistent user interface. It prevents reinventing
the wheel, and will be easier for the DDU team to just link with the
library when it is ready.
4) I also ran by Frank that the DDU will possibly need to configure the
network (if it is given the command to automatically install missing
drivers (which requires a repo), or if it otherwise needs to go to a
repository or a URL on the net). We agreed that if the DDU requires the
net, it will try to bring up the network automatically first (a la DHCP
/ NWAM). If it can't for some reason (maybe the net doesn't have a DHCP
server), then the user will be asked if the network should be set up,
and then presented with the network setup screen. (Screen would likely
have different text but the same choices as the installer's "manual"
network setup screen.)
Questions/comments/corrections invited.
Thanks,
Jack
