On Thu, May 31, 2001 at 02:30:34PM -0600, Ronald G Minnich wrote:
> I don't think any of that is a Really Bad Idea. GUI programming is usually
> beyond my capabilities. If you can build some sort of demo I think I'd
> like to see it.
I'll work on this. Time being what it is, it won't be tomorrow
morning or anything.
> My only request: there should always be a good scriptable interface. GUI
> should not be a requirement. Scriptable is good because one thing I need
> is a regression test, so we can buld every linuxbios target every night
> and catch errors.
I agree and should have mentioned this. In my thinking,
the GUI aspect of the config tool should largely be a
crutch to help in the construction of a properly-formed
configuration file, or to aid in the editing of an existing
one, not unlike the way in which the "make xconfig" helps
to prepare a .config file for the Linux kernel.
I imagine three basic run modes:
1. GUI. A starting config file can be provided, but is optional;
if provided the config file will be used to set defaults.
2. Interactive/Non-GUI. A starting config file is required,
much as is the case today. The program can -- but isn't
required to -- offer text prompts in an effort to resolve
ambiguity or errors. A new config file can optionally be
saved which reflects the changes as a result of user
responses.
3. Batch. Again a config file is required, but no user input
will be allowed. Stdin will (either in effect or reality)
be closed on startup. Errors and informational messages will
go to stderr and stdout or to log files according to runtime
options.
It is unclear to me whether it would be worth the effort to
have additional run modes to allow config file editing in a
text window (a la "make config") or full-screen, perhaps
using Red Hat's "newt" library (used for their text-mode
installer and the "setup" command). My guess is not.
--Bob
