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 <[EMAIL PROTECTED]>
|A computer scientist is someone who fixes things that aren't broken.
`--------------------------------------------------------------------
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
