Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!apple!bloom-beacon!mit-vax!josh
From: josh@mit-vax.LCS.MIT.EDU (Joshua Marantz)
Newsgroups: comp.windows.x
Subject: Re: Detecting/Compressing Multiple Exposure Events - how ?
Message-ID: <4690@mit-vax.LCS.MIT.EDU>
Date: 6 Sep 88 23:55:37 GMT
References: <19880831130506.7.RWS@KILLINGTON.LCS.MIT.EDU> <130@tityus.UUCP>
Organization: MIT LCS, Cambridge, MA
Lines: 54
In-reply-to: jim@athsys.uucp's message of 1 Sep 88 21:36:01 GMT


JDM> Currently, I have to emulate that functionality with an XCheckIfEvent
JDM> followed by an XPutBackEvent, which has the annoying side effect of
JDM> rearranging the event queue.

RWS> As I pointed out in a previous posting, by using the arg value you can
RWS> avoid having to pull anything out of the queue...
RWS> ...  If people feel strongly that
RWS> additional routines ought to be provided in some sort of utility library
RWS> on the MIT release, we're willing to listen (and take code that comes
RWS> with documentation).

JB> [Paraphrased]
JB> By modifying the XCheck*() routines to accept a NULL event pointer and
JB> take it to mean that the event should not be removed from the queue, my
JB> problems can be solved efficiently without breaking anyone else's code
JB> and with minimal coding work from the X Consortium.  The arg modification
JB> proposed by RWS is functional but potentially inefficient and arguably
JB> unaesthetic.

If Jim Becker's change were implemented for R3, it might present a backwards
compatibility problem:  if I write my code for an Xlib that accepts NULL
events in XCheckIfEvent, then my code won't work correctly on a vendor's
library, since they typically lag the MIT version by a few months.  This
may not be so important to some people, but it would be to others.

I like RWS's other suggestion -- using a custom WireToEvent routine.
As described on page 243 of the MIT, Xlib manual, in the extensions
section, the routine XESetWireToEvent will allow you to define a
routine to intercept events before they are placed on the queue.  This
routine could update your own data structure saying which events are
pending.  It could then call the default WireToEvent routine, which is
returned by XESetWireToEvent.  This is a nice little design, since
several independent modules can intercept events, process them, and
then call the previous handler.

My only problem with it is that the manual says:

XLib> You can replace a core event conversion routine with one of your own,
XLib> though this is not encouraged.  It would, however, allow you to
XLib> intercept a core event and modify it before being enqueued or
XLib> otherwise extended.

Should I take this to mean that I am treading on thin ice in terms of
portability by using this routine?  Or am I OK so long as I call the
default handler and return its status after doing my own filtering?

Also, the documentation is confusing as to whether my routine is
supposed to return an "int" or a "Status", since XESetWireToEvent
returns an integer procedure pointer.  I suppose they are ultimately
the same thing, but I haven't checked yet.

-Joshua Marantz
Viewlogic Systems, Inc.