skinner@saber.UUCP (Robert Skinner) (12/13/85)
> >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
miner@ulowell.UUCP (Richard Miner) (12/15/85)
There are window standards being worked on by ANSI! At the last X3H3 meeting there was a small subgroup X3H3.win that spun of to start specification of this standard. On of my Prof's here at U Lowell is on this committe. I will try and get a brain-dump from him, and post the status of this standard to the net. I must agree with previous note, GKS and CGI are NOT window standards, nor do they specifiy how to interface withh windows. CGI might be a nice base for a window system/standard but GKS ugg to big, with to many layers (in most cases) to add Wind managment on top of. I speak after a summer of so a GKS implementation on top of a (pseudo)CGI. Rich Miner decvax!wanginst!ulowell!miner /** * From Ulowell - (soon to be) Home of a cheap GKS w/source. */
johnd@kvvax4.UUCP (John Dibble) (12/17/85)
> > There are window standards being worked on by ANSI! At the last X3H3 > meeting there was a small subgroup X3H3.win that spun of to start > specification of this standard. On of my Prof's here at U Lowell is > on this committe. I will try and get a brain-dump from him, and post > the status of this standard to the net. > > I must agree with previous note, GKS and CGI are NOT window standards, > nor do they specifiy how to interface withh windows. CGI might be a > nice base for a window system/standard but GKS ugg to big, with to > many layers (in most cases) to add Wind managment on top of. I speak > after a summer of so a GKS implementation on top of a (pseudo)CGI. > > Rich Miner > decvax!wanginst!ulowell!miner > > /** > * From Ulowell - (soon to be) Home of a cheap GKS w/source. > */ *** REPLACE THIS LINE WITH YOUR MESSAGE ***