Xref: utzoo comp.graphics:1803 comp.sys.mac:13216
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!denali!karish
From: karish@denali.UUCP (karish)
Newsgroups: comp.graphics,comp.sys.mac
Subject: Re: GKS on MAC II
Message-ID: <8@denali.UUCP>
Date: 26 Feb 88 05:16:28 GMT
References: <943@ut-emx.UUCP> <3468@ece-csc.UUCP>
Reply-To: karish@denali.stanford.edu (Chuck Karish)
Organization: Stanford University School of Earth Sciences
Lines: 74

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