Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Dec 1997 19:36:16 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Alex <garbanzo@hooked.net>
Cc:        "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:  <29598.881033776@time.cdrom.com>
In-Reply-To: Your message of "Mon, 01 Dec 1997 18:47:12 PST." <Pine.BSF.3.96.971201184258.2963D-100000@zippy.dyn.ml.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Huh?  I was thinking that you should say put (& make) functions like for
> instance, install distrubition, and most of the other options under the
> configure menu in a libraray, and use TurboVision (or whatever) as a
> wrapper for that.  That way, one could use C (and their favorite widget

It's not quite that simple, I'm afraid.  Sure, you can always
implement the core functionality of "sysinstall" as a series of
libraries which could conceivably be used by other installers - one
could arguably say that this is already the case today with things
like libdisk, libdialog, and the pkg_install tools being stand-alone
items which sysinstall also relies heavily on to do its own work.  Not
much *in* /usr/src/release/sysinstall itself, really, except for lots
of grotty glue code to hang it all together and perhaps one or two
small subsystems which might conceivably be library-ized to some
useful purpose (though I can't think of what at the moment, to be
honest).

It's the UI which is the principal problem here, and layering
reasonably simplistic UI abstractions on top of TurboVision is rather
difficult given that TV is a seriously C++-ish toolkit which rather
expects you to subclass all of your UI objects from its own and derive
your more specific behavior in the other direction.  If I went to the
abstract UI model, I'd simply implement the appropriate objects in
ncurses and toss TV.  However, since TV also happens to be the best
looking toolkit we've got or have seen to date, we're probably going
to be stuck doing interfaces its way.  The alternative is to either
get lost in the problem of trying to map the very OOPish TV toolkit to
some non-OOP scripting language like TCL* or to spend some seriously
ugly time with ncurses in generating the "most common denominator"
interface objects for your UI-neutral installation tool.  With TV, one
could just dive in and start prototyping pieces of the interface with
a high degree of reusability for the final 3.0 installation product.
It's kind of a choice between purity and pragmatism, basically. :(

Another option which hasn't really been explored is the idea of using
TurboVision's UI model and making an API compliant version that uses X
windows for all the various objects, e.g. you just write the
installation utility as a wrapper which loads the main body and the
turbovision library of choice dynamically based on $DISPLAY.  But
someone would also have to be insane enough to do a version of TV for
X. :-)

					Jordan



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