Date: Sun, 30 Nov 1997 22:43:09 -0800 (PST) From: Alex <garbanzo@hooked.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> 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: <Pine.BSF.3.96.971130223423.17886A-100000@zippy.dyn.ml.org> In-Reply-To: <19737.880955544@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Nov 1997, Jordan K. Hubbard wrote: [snip of reasons why X only systems would be as impossible as Win95] Sadly, I would have loved to run X on my laptop, but it seems IBM hadn't gotten the hang of making conformists out of its ThinkPads when it was made. However, I wasn't thinking ditch the cli, I was thinking in addition to, as I (and I'm sure many other people) are still wrestling to get X working consistantly. > 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. :-) What about making some of the basic sysinstall (or whatver) functions into a shared library, rpm and librpm come to mind. That way a command line based installer could add its own menu on top of that, and a GUI one could add it's own thing on top of that. Plus, it would have an advantage of seperating the UI and "low-level" stuff somewhat, so that bugs in one, wouldn't necesarily force a re-compilation of the other. > 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. :-) I never did much like TurboVision, although I still hope the nameless "new installer" makes it into 3.0-release ;-) - alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971130223423.17886A-100000>