Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Nov 1995 09:03:01 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Michael Smith <msmith@atrad.adelaide.edu.au>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Thoughts on the install and on Red Hat Linux. 
Message-ID:  <2161.817491781@time.cdrom.com>
In-Reply-To: Your message of "Mon, 27 Nov 1995 01:48:25 GMT." <199511270148.BAA02573@genesis.atrad.adelaide.edu.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Hmm.  Two days ago you were saying "it can't be done!" (or for the
> australians here, "we'll all be rooned!"), wrt. leap to X.  Has this
> changed your mind?  (I'm being optomistic here 8)

Well, let's just say that I'm more open to the possibility.  It's
kinda moot until we get the proof-of-concept implementation
out there and get some feedback on it anyway.. :-)

I didn't get any feedback about my suggestings surrounding the
re-architecting of xf86config, however.  Both Rich Murphy and David
Dawes have "signed on" at least in principle to the idea of us
spearheading a new cross-platform X setup utility.  If it depends on a
GUI library we also ship, I don't see that as a real significant
hardship.  I'm already planning to fly out and see Patrick Volkerding
(of Slackware) pretty soon to talk about the very subject of more
work-sharing between the two groups.  Out in user land, we've very
few excuses to re-invent the wheel.

> Do we want the forms shell to go so far as to do traversal, or to just run
> a given form?  (I see traversal as being a bit tougher, and I'm not sure 
> what we gain from it, other than yet another interpretive language 8( )

I think you may have misunderstood me.  Go take a look at
/usr/src/release/sysinstall/tcpip.c and see the fairly gross
application-side buggery that's required to deal with the various text
entry fields on that "form".  If you look at any of the classic forms
interface languages out there, they basically have a way of saying "I
have these fields, on this form, and if the user is tabbing through
them then visit the fields in theis order."

The really simple forms IDLs just provide you with a canned set of fairly
opaque objects and an API for reading forms that contain them from files.
The slightly more complicated ones give you objects with more advanced
capabilities, like field masks (###.##) and input validation, user
defined input/entry/exit check routines, etc.  The really really
advanced ones just spit out code from a schema and let you imbed your
own stuff into the resulting template, but I'm not sure I've ever liked
that approach very much.

> Ah drat.  I was looking to the forms interpreter as a seperate shell on
> the end of a pipe, reading forms and returning the result.  We can still
> do callbacks like this, it's just a little more work.

Erm.  I think you're over-complicating it - next you'll suggest a full
XDR/RPC mechanism for communicating with the forms task, even if it's
running on another machine.. :-) I think just a plain 'ol C library
will do the job just fine, running in the same process.  As long as
you can read a form, tie callbacks to its members (id'd by name so
it's at least decoupled somewhat - e.g. you can change the underlying
forms object just so long as you keep the name the same) and then
say "go get me the values from this form" in one easy call, with
the forms code calling you back as necessary, well that would certainly
do it for me.

The existing libforms has/had many of those abilities.  Perhaps we
should visit it again?  I know that Paul R. put a fair amount of
work into it.

> Ok, I'm sold on TCL.  I know it's not perfect, but it's a _common_ language,
> so the available programmer-base is much larger.  Can we win the war to get
> tcl into the base distribution? 8)  This "devision" should go well with
> John's recent post wrt. the 16-step plan to a tighter installation.

Well, Peter has been fighting the war as a rear-guard action for
months now.  The only question usually is: Which versions?  3.6/7.3?
4.0/7.4?  4.1/7.5?  Once we can settle this question, we can start
thinking about finding a bmake'd version.

					Jordan



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