Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!pie1.mach.cs.cmu.edu!egc
From: egc@pie1.mach.cs.cmu.edu (eddie caplan)
Newsgroups: comp.windows.x
Subject: Re: event-driven X11
Message-ID: <5303@pt.cs.cmu.edu>
Date: 23 Jun 89 15:56:22 GMT
References: <2069@gmu90x.UUCP>
Distribution: na
Organization: Carnegie-Mellon University, CS/RI
Lines: 23

well the mail still hasn't slowed down...

i see it this way: X is just glorified I/O.  just because i want to write a
program that does I/O doesn't mean that i want it to be I/O *driven*.
likewise, if i want to write a program that does some X doesn't mean that i
want it to be XEvent *driven*.

using XCheckIfEvent(), i can have my program be driven by some other factor and
still periodically look for Exposes, etc.  but then i can only pick up XEvents
when my other factor triggers.  if the X protocol would support a scheme where
i could get an interrupt when one of my selected XEvents occurs, then this
problem would be solved.

with XToolkit i am even worse off.  i must call a never-returning XtMainLoop()
which prevents me from using the XCheckIfEvent() solution.  so if i want to be
driven by some other factor AND use XToolkit then my other factor must generate
the interrupts.  but suppose that that other factor is like X and doesn't offer
any method to generate interrupts?  this is exactly the situation for my
project.

so.... please stop telling me that "all X programs MUST/SHOULD be event
*driven*".

--