setup dialog from scripts is more controllable. No more biasing off of
hostname (which is now non-optional in the non-netInteractive case).
Requested by: pst
so that we're more useful in multi-user mode. This is still not
100%, but it pulls in a lot more than it used to. Some of the "composite"
variables in /etc/sysconfig are going to take more work.
o Always write /etc/resolv.conf and /etc/hosts if it makes sense to do
so.
o Reset media properly when reselecting. Longstanding bogon.
o Pull SIGPIPE handling out of package.c; I'm actually hoping to handle
this differently shortly.
o Fix bug where cancel in TCP setup dialog still checked data fields.
I think this closes a PR, but I will have to go look.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
bogus or overly complex and really needed to be done more consistently
and sanely throughout - no question about it. Done.
Suggested-By: Paul Traina <pst@Shockwave.COM>
Some changes of my own to make screen saver configuration a little
more sane, and also make it easier to get to the keyboard/screen
setup from the options menu.
I still have a _very very annoying_ display bug which occurs when a menu
item causes a submenu to be displayed - the screen repaints for the original
menu (which is restored upon return from the submenu) are off by about 4
characters. I've tried restoring the screen, the cursor position, you name
it - same deal. Grrrr! This commit is my first step in trying to get someone
else to help me look into this one since I'm just tearing my hair out at this
point!
1. Use new dialog menu hacks (no strings, just arrays of dialogMenuItem structs)
so that I can create composite menus with radio/checkbox/... items in them,
removing some long-standing UI bogons in various menus. This work isn't
finished yet, but will be done in two phases. This is phase one.
2. Remove all the script installation stuff. I never got time to document it,
it was arcane and it just complicated much of the code. There are better
ways of doing this if I want to do auto-driven installations later.
3. Remove much dead code and otherwise attempt to remove as much historical
grot as possible so that this code is easier to hack on. This is also
a two-stage process, phase one of which is now complete.
This looks like it was developed offline, and is being spammed over the
top of the existing. "That's fine by me! I dont really care how you do
it, just get it in there..." said Jordan in a conversation a short while
ago...
