jezebel@ut-emx.UUCP (Jim Saint) (02/24/88)
Does the MAC-II support GKS ? Thanks Jim
jnh@ece-csc.UUCP (Joseph Nathan Hall) (02/25/88)
*** EAT THIS *** In article <943@ut-emx.UUCP> jezebel@ut-emx.UUCP (Jim Saint) writes: >Does the MAC-II support GKS ? >Thanks >Jim (See summary line, above.) I've been using GKS on a VAXstation GPX for almost a year now. The worst niggling-type problem with GKS under VMS is that GKS is really designed to run under FORTRAN (that's right) and so all the "C" calls are by reference (uggh) and many of the string paramegers use descriptors (double uggh). Aside from that, GKS is basically bloated, illogical and inefficient and I can't understand why anyone would want to use GKS on a Mac instead of QuickDraw. You might want, I suppose, to port an existing GKS application from a Sun or VAXstation to a Mac. Good luck. The only standardized binding is for FORTRAN. (Can you imagine writing in a non-stack-based environment on a Mac???) So whatever happens you're going to spend some time changing all the calls to, say, gks$clear_ws() (on VMS) to ClearWs or something like that on your Mac. I'm sure the parameters are in a different order, too. GKS is not device-independent in an intelligent way, either. Basically you have to write code to support each individual device. Some devices support multiple windows, some don't--you write differently for each. Some are monochrome, some are color. Text is different sizes. Markers are different sizes. Et cetera. The worst part of the GKS interface is its rather carelessly designed I/O. Under VMS the only way to input a string is to: 0) Before you do anything with any of the input devices you have to call a routine to get the device coordinates, if you want to place your echo area (where the window will be) in a particular spot. The echo area is defined in terms of device coordinates. 1) Call gks$init_string to set up a window for the string input. This may include a title for the window, but there are problems (VMS-specific) with this, and it only works on the VAXstation. This means, basically, YOU CAN'T PROMPT for string input under the letter of the GKS standard. Any prompting is implementation- specific. 2) Call gks$request_string to get the string. You can't specify the SIZE or FONT of the type inside the input window. You can't input more than one line (nothing like TextEdit). Basically you can't do much more than take a few ugly-looking characters worth of input using the GKS string input routines . . . . I could list annoying "features" until my fingers fall off. I've been writing a user interface for a network analysis CAD tool and certainly having to deal with GKS has been the most difficult part of this project (unfortunately we're stuck with it). I would kill to be able to wad up all these GKS hacks and write a nice, clean Mac interface. GKS? Yuck. -joseph /* * What, me worry? * * These are my opinions. I'm sure everybody else agrees with me, but, * you know. */ *** EAT THIS ***
darin@laic.UUCP (Darin Johnson) (02/26/88)
In article <3468@ece-csc.UUCP>, jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: > *** EAT THIS *** > > In article <943@ut-emx.UUCP> jezebel@ut-emx.UUCP (Jim Saint) writes: > >Does the MAC-II support GKS ? (does it support anything useful for that matter?) > I've been using GKS on a VAXstation GPX for almost a year now. The worst > niggling-type problem with GKS under VMS is that GKS is really designed to > run under FORTRAN (that's right) and so all the "C" calls are by reference > (uggh) and many of the string paramegers use descriptors (double uggh). Actually, this is more of a problem with VMS in general, not GKS. I haven't used GKS that much, but have used VMS quit a bit (been forced to use I should say). Programming is a breeze if you are using FORTRAN, but a pain in the butt for anything else. In particular, descriptors are done automatically in FORTRAN, but have to be built by hand in other languages. I would assume that descriptors are used with GKS in order to interface with FORTRAN better, not that GKS itself needs descriptors (I seriously doubt that any other OS has descriptors in the same format anyway). I haven't seen GKS on a UNIX machine, but a would suspect that the C interface has no descriptors or pass by reference parameters. > Aside from that, GKS is basically bloated, illogical and inefficient and I > can't understand why anyone would want to use GKS on a Mac instead of > QuickDraw. (I can't understand why anyone would want to use a Mac :-) > You might want, I suppose, to port an existing GKS application from a > Sun or VAXstation to a Mac. Good luck. The only standardized binding is > for FORTRAN. (Can you imagine writing in a non-stack-based environment on > a Mac???) For SunCORE at least, there was a library for C (and similar languages) and a separate FORTRAN callable library. Something similar to this should be easily done by anyone who implements GKS. (Trying hard to force myself not to say anything bad about Mac's or VMS) -- Darin Johnson (...ucbvax!sun!sunncal!leadsv!laic!darin) (...lll-lcc.arpa!leadsv!laic!darin) All aboard the DOOMED express!
karish@denali.UUCP (karish) (02/26/88)
In article <3468@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >I've been using GKS on a VAXstation GPX for almost a year now. The worst >niggling-type problem with GKS under VMS is that GKS is really designed to >run under FORTRAN (that's right) and so all the "C" calls are by reference >(uggh) and many of the string paramegers use descriptors (double uggh). This criticism applies to one implementation, not to GKS itself. DEC chose to make their own C binding for GKS by porting the official FORTRAN binding, instead of tracking the draft C binding. The C binding is pretty reasonable. It uses structures where appropriate, and does use call-by-value. Part of the delay in getting the C binding finalized is that the C language is not yet standardized! A key issue for GKS is whether C will allow structures to be passed by value. >You might want, I suppose, to port an existing GKS application from a >Sun or VAXstation to a Mac. Good luck. The only standardized binding is >for FORTRAN. The C binding is pretty stable by now (drafts have been available for two years), and is usable. >So whatever happens you're going to spend some time changing all >the calls to, say, gks$clear_ws() (on VMS) to ClearWs or something like that >on your Mac. I'm sure the parameters are in a different order, too. Huh? gks$clear_ws() isn't a name defined in the GKS standard. This refers, again, to a stop-gap implementation. >GKS is not device-independent in an intelligent way, either. Basically you >have to write code to support each individual device. Some devices support >multiple windows, some don't--you write differently for each. Some are >monochrome, some are color. Text is different sizes. Markers are different >sizes. Et cetera. Is quickdraw device-independent AT ALL? GKS provides many inquiry functions which the programmer can use to find out the device's capabilities. Of course, you program differently for different devices. GKS lets you write programs that can adapt to different types of displays, at run time. >The worst part of the GKS interface is its rather carelessly designed I/O. >Under VMS the only way to input a string is to: [description of programming steps deleted] "I/O" (really, support for interaction) is not spelled out in the standard because it's inherently device-specific and because it is a higher-level problem than what the committee thinks should be in a 'kernel'. Support for things like sizing windows and setting up dialog boxes on a particular device should be in a higher-level interface library. The expectation was that programmers would write functions of this sort as needed, using primitives from GKS. Such a library would keep the device interface out of the programmer's way, where it belongs. >I would kill to be able to wad up all these GKS hacks and write a nice, clean >Mac interface. Then sell it to someone who wants to run it on a GPX, or a SUN, or an IRIS? GKS suffers both from trying to be as general as possible, and from having been designed by a large committee. It's still one of just a few vehicles for writing portable graphics code. The inertia of the committee approach may cause GKS to fall by the wayside, unless more language bindings and a 3-D version are standardized before everyone loses interest. My employer is not so foolish as to agree with all of my opinions. Chuck Karish ARPA: karish@denali.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish paper: 1825 California St. #5 Mountain View, CA 94041
rcb@rti.UUCP (Random) (02/26/88)
In article <166@laic.UUCP> darin@laic.UUCP (Darin Johnson) writes: >Actually, this is more of a problem with VMS in general, not GKS. >I haven't used GKS that much, but have used VMS quit a bit (been forced to use >I should say). Programming is a breeze if you are using FORTRAN, but a >pain in the butt for anything else. In particular, descriptors are >done automatically in FORTRAN, but have to be built by hand in other >languages. Actually, Descriptors are done automatically for ALL VMS languages except C. Since C is the only language that does not have some form of string datatype (not array of char), a descriptor cannot be easily formed for the array of characters that it uses for a string because it may not be being used as a string but as an array of characters. All the other languages leave low level choices to the compiler (like value/reference parameter passing, register allocation, etc.) -- Randy Buckland (919)-541-7103 Research Triangle Institute rcb@rti.rti.org [128.109.139.2] {decvax,ihnp4}!mcnc!rti!rcb