Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 / ST 1.0; site saber.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!nsc!saber!skinner
From: skinner@saber.UUCP (Robert Skinner)
Newsgroups: net.lang.c,net.micro.mac,net.micro.atari,net.micro.amiga,net.graphics
Subject: Re: Windows ( Really porting between Mac, Amiga, and ST
Message-ID: <1886@saber.UUCP>
Date: Fri, 13-Dec-85 13:14:03 EST
Article-I.D.: saber.1886
Posted: Fri Dec 13 13:14:03 1985
Date-Received: Sun, 15-Dec-85 00:14:33 EST
References: <-13400@brl-tgr.UUCP> <116@ISM780C.UUCP> <424@tekig4.UUCP>
Organization: Saber Technology, San Jose, CA
Lines: 54
Xref: watmath net.lang.c:7401 net.micro.mac:3804 net.micro.atari:1970 net.micro.amiga:1113 net.graphics:1343

> >Until someone actually writes those libraries, I don't think one will
> >see a lot of portable code between these machines, except for programs
> >that use a simple command line user interface.
> >
> >Sounds like a job for an ANSI committee! :-)
> 
> Unfortunately, the ANSI bureaucracy has done just that, and called the result
> GKS.  If anything it serves only to show the futility of the effort.  In order
> to be all things to all people in all ways, any such implementation must be
> huge, slow, unwieldy, and generally unusable.  Guess what?  GKS is huge, slow,
> unwieldy, and generally unusable.  It is appropriate only for those with
> giant machines, the likes of which the world doesn't use much any more.
> 
> -Brian Diehm

To the best of my knowledge, GKS was never intended to solve the
problems of windowing software.  It is Device Independent Graphics
Application Utility.  It supports output to multiple devices, in
multiple viewports and Graphic windows, but only from one process.  It
never attempts to address overlapping windows belonging to different
processes.  I suppose one could build a window manager on top of GKS
and treat different windows as different devices (workstations) and
using segments to restore obscured windows.  But that is just using a
good program badly.  It just doesn't apply.

ANSI X3H3 met in October to discuss the issues of display management
(such as window assignment and priority), color table arbitration
(which window controls the color table), and communication between
mouse, keyboard, and icons.  "We won't be standardizing the user
interface, but we'er looking to standardize ways the programmer tells
the operating system what he wants to happen on the screen", Peter
Bono.  I haven't heard the results of this meeting.

Every window manager has different syntax for defining a window,
moving it around, creating subordinate windows.  Whether a window is
updated implicity or explicitly after a change.  Where the graphics
information is stored that restores obscured windows (is it a BitBlt, or
a display-list?).  How the graphics information is defined is the job
of GKS, or CGI.  Both of those standards have features which are
applicable to the window problem, but they are not intended to be
solutions to it.


I have cross-posted this to net.graphics, I believe the discussion
should continue there.  I think it should be removed from net.lang.c.


------------------------------------------------------------------------------

Name:	Robert Skinner
Snail:	Saber Technology, 2381 Bering Drive, San Jose, California 95131
AT&T:	(408) 945-0518, or 945-9600 (mesg. only)
UUCP:	...{decvax,ucbvax}!decwrl!saber!skinner
	...{amd,ihnp4,ittvax}!saber!skinner