From owner-freebsd-hackers Mon Dec 1 19:36:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21500 for hackers-outgoing; Mon, 1 Dec 1997 19:36:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21495 for ; Mon, 1 Dec 1997 19:36:28 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id TAA29603; Mon, 1 Dec 1997 19:36:16 -0800 (PST) To: Alex cc: "hackers@freebsd.org" Subject: Re: Out of Box experience (Was: Re: How is selection made of what goes into CDrom?) In-reply-to: Your message of "Mon, 01 Dec 1997 18:47:12 PST." Date: Mon, 01 Dec 1997 19:36:16 -0800 Message-ID: <29598.881033776@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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