Date: Tue, 14 Dec 1999 17:37:14 -0600 From: Chris Costello <chris@calldei.com> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: Donn Miller <dmmiller@cvzoom.net>, Eric Jones <ejon@colltech.com>, current@FreeBSD.ORG Subject: Re: sysinstall: is it really at the end of its lifecycle? Message-ID: <19991214173714.W868@holly.calldei.com> In-Reply-To: <2683.945164965@zippy.cdrom.com> References: <3855F364.E66EC87B@cvzoom.net> <2683.945164965@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 14, 1999, Jordan K. Hubbard wrote: > That's one of the design precepts of the New System, in fact. There > is one common UI abstraction which sysinstall II (hereafter referred > to as Setup) and the new package system both use. The generic UI > front-end API is "bound" at runtime to a back-end implementation > class, the two currently supported ones being Qt and Turbovision (the > references implementation for the common UI stuff is all written in > C++), and everything pops up in the appropriate UI environment from > that point forward. Our test code checks for $DISPLAY and does the > appropriate Qt magic in that case, otherwise it binds in Turbovision. > In theory, one could even write a back-end class which talked to a > browser. Scary. :) Is Qt going to be put into the base system in this case? If I can wrestle along with figuring out a few little problems with Qt (ones that I could even somehow more easily solve with Motif!), then I'll continue to develop my system administration tool(s) with it. Another possible solution I was thinking about (but will probably really regret) is keeping a binary distribution and enabling source builds only if a Motif or Lesstif port is installed. Yes, this implies that I would write it in Motif. And yes, I'm also sure that it will meet with much disagreement. > In order to ensure that the package's installation routines call the > common UI routines for all their interaction needs (remember the VTY2 > scenario), a package's installation script is also now assumed to be a > secure TCL script rather than being the arbitrary executable it is > now. This has a number of implications even more important than > simple interface unification, of course, most of them in the realm of > security. So is all of this (TCL, Qt, et. al.) going into the base system to facilitate this work? -- |Chris Costello <chris@calldei.com> |A computer scientist is someone who fixes things that aren't broken. `-------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991214173714.W868>