From owner-freebsd-hackers Mon Nov 27 09:05:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA13277 for hackers-outgoing; Mon, 27 Nov 1995 09:05:32 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA13272 for ; Mon, 27 Nov 1995 09:05:28 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA02163; Mon, 27 Nov 1995 09:03:01 -0800 To: Michael Smith cc: hackers@FreeBSD.ORG Subject: Re: Thoughts on the install and on Red Hat Linux. In-reply-to: Your message of "Mon, 27 Nov 1995 01:48:25 GMT." <199511270148.BAA02573@genesis.atrad.adelaide.edu.au> Date: Mon, 27 Nov 1995 09:03:01 -0800 Message-ID: <2161.817491781@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > 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