Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Nov 1997 21:52:24 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Alex <garbanzo@hooked.net>
Cc:        Jacques Vidrine <nectar@NECTAR.COM>, "hackers@freebsd.org" <hackers@FreeBSD.ORG>
Subject:   Re: Out of Box experience (Was: Re: How is selection made of what goes into CDrom?) 
Message-ID:  <19737.880955544@time.cdrom.com>
In-Reply-To: Your message of "Sun, 30 Nov 1997 21:33:14 PST." <Pine.BSF.3.96.971130212834.13855A-100000@zippy.dyn.ml.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> That was me who suggested _that_.  I still think that a graphical
> counterpart of sorts to sysinstall or its successor, (which you are 
> writing right? ;-) ) is something, that would certianly add a little bit
> of polish to FBSD, and perhaps increase its userbase.  While I'm kinda

Sure would, but the bootstrapping issues are hard.  To use an X based
anything, be it Qt or (to be more politically correct) Tk based,
requires that you get the user fully into a running X environment
first and that's often very hard, especially if the user in question
happens to be missing a couple of blades on his propeller, if you get
my drift.  I've got a machine here which can't even run the VGA16
server on its funky graphics card, and I've heard others say the same
of various laptops and other funky gfx card infested systems.
Considering that a goodly number of those might not even want to *run*
X, it hardly makes sense to tell them that they still need it just to
install the system.

An alternative, of course, is to provide an installer which does one
or the other based on some initial user dialog, but writing such a
dual-headed installer is also *hard* if you only want to have to keep
one central source code base updated every time you add something to a
menu or change the ordering of the install (and that *is* the way you
would want to do it, the option of maintaining two installers in
parallel being a very painful one over the long term).  That requires
a fairly abstract UI subsystem which is able to use arbitrary
interface objects in dialoging with the user and can use any given set
on the fly.  I haven't seen this holy grail of interface technology
available for free yet, so don't hold your breath on that ever
happening unless you become a really good C programmer sooner than
expected. :-)

I suspect that what will happen instead, given the time pressures
currently on the "new installer" project (and its stunning lack of
substantial progress so far), is that a reasonably decent CUI library
like TurboVision will simply get used in place of the egregious
libdialog, the X-heads continuing to run it inside an xterm and just
coping with that fact. :-)

					Jordan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19737.880955544>