Path: utzoo!attcan!uunet!husc6!think!bloom-beacon!mit-eddie!uw-beaver!cornell!batcomputer!garry
From: garry@batcomputer.tn.cornell.edu (Garry Wiegand)
Newsgroups: comp.graphics
Subject: Re: Mixing window system and graphics operations
Message-ID: <5226@batcomputer.tn.cornell.edu>
Date: 20 Jun 88 02:52:04 GMT
Reply-To: garry@oak.cadif.cornell.edu
Organization: Cornell Engineering && Ithaca Software
Lines: 27

In a recent article sxm@bebop.philips.com (Sandeep Mehta) wrote:
>I wonder if anybody else had faced the following problem, and found even a
>partially optimal solution. I am writing some 3D object modelling software
>which needs to be interactive i.e. I want control over objects displayed
>in a window using window system toolkit primitives ...

In the course of porting Hoops to the Mac we noticed that allowing the
graphics library and the user program to share the use of the screen/window
wasn't very hard - most window systems seem to be fairly clean in keeping
popups and such from different sources out of each other's hair. 

However, as you noticed, figuring out how to untangle the stream of 
events coming back is a tougher problem. What we ended up having to do 
was to create a new kind of event in our system - a generic "special"
event - and then we arranged to queue one of those back with appropriate
info to the user program whenever an "unexpected" windowing system 
event is encountered.

It would be nice to be able to work the other way too - to let the user 
program be in charge of the window system event queue and choose to hand 
some things over to Hoops for interpretation... I'll see what we can do :-)

(The Mac is just the case at hand - we'll have to do the same for our
 new releases on the Sun, on X, on the Presentation Manager, etc etc etc )

garry wiegand   (garry@oak.cadif.cornell.edu - ARPA)
		(garry@crnlthry - BITNET)