Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!noc.netcom.net!news.sprintlink.net!in2.uu.net!tcsi.tcs.com!agate!violet.berkeley.edu!jkh From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Object-oriented what? (was: Future of FreeBSD) Date: 16 Aug 1995 07:14:02 GMT Organization: University of California, Berkeley Lines: 61 Message-ID: <40s5rq$397@agate.berkeley.edu> References: <DC6vJ3.L53@news.central.com> <3vlv5m$aii@park.uvsc.edu> <id.037M1.WI4@nmti.com> <40qcjc$pps@jeeves.niehs.nih.gov> NNTP-Posting-Host: violet.berkeley.edu In article <40qcjc$pps@jeeves.niehs.nih.gov>, Dave Duling <duling@niehs.nih.gov> wrote: >Interesting thread. It seems that BEFORE a group can decide upon a GUI >toolset, it must first decide upon a GUI ! FreeBSD (and Linux for >that matter) run generic X-windows fine, but without Motif there is no >standard for what sliders, buttons, windows... etc... look like or how >they behave. Do you want mouse focus windows or mouse click focus windows ? Well, I think that Tk isn't a bad choice if you're looking for some sort of "standard" for such things, and I think that having an interpreted language for GUI development certainly helps when you're at the "fiddling and tweaking" stage of evolving the interface since doing development on top of the raw Motif API sucks deceased marmots through thousands of meters of oil-encrusted Alaska pipeline. If you have something like UIM/X running on top then at least you're only sucking very small dead gerbils through garden hose by comparison, but you still need to convince the UIM/X folks to port their toolkit to FreeBSD and I don't think that's likely to happen anytime real soon. So once you start taking all that into account, Tk starts looking better and better. It's just too bad there's still no reasonable "GUI builder" for it. I tried working with some of the current offerings and they just made me too frustrated with their general lack of understanding about what makes a good GUI builder (use reasonable defaults and don't make the user fill in a 700 entry property sheet for each object unless they really really want to). Perhaps, with time, that will change. I know that since John O. went to Sun they've been funding such an effort and hopefully we'll see it soon. That'd be cool, though I can't help but wonder how some of their customers must feel: "Buy Sun and get out GUI of the week! First we told you that Open/Look was it, but we lied. Then we told you to use Motif instead, but only as part of CDE which will be out in a usable form Real Soon Now. As soon as you get used to that, however, we'll ask you to drop it all and go to our new hyper-Tk interface builder that also interfaces to HotJava! What do you *mean* you don't trust us now?! Have we ever lied to you?? Well, that is anytime within the last five minutes?" >both ? How will these GUI objects be distributed over the network ? Do I don't think that this is a GUI problem. If your underlying application requires distribution then you distribute the DATA and leave the GUI visualization local. Only a very insane person would try to send the GUI calls across the network. Well, not if you don't count X, anyway. >you want client-server tools built into the OS+GUI or make them entirely >from libs ? You wouldn't use a Win32 compiler to make an OS/2 program, and Yeesh! I don't think we need to put client-server tools into the OS. Plenty of room for them up above, with whatever CORBA compliant library you've standardised on. There's always ORBIX. >One interesting starting point might be to look at the Caldera release. >Could that be ported to FreeBSD ? It would certainly be nice to have >some GUI portability between the two. I don't think Caldera tries to be a GUI standard so much as a simple *desktop* standard and I certainly agree that we could use one of those. I'm still waiting for someone to send me a URL pointing at the code, of course.. :) Jordan