[winGRASS] libG11

Glynn Clements glynn.clements at virgin.net
Mon Oct 1 18:34:55 EDT 2001

Malcolm Blue wrote:

> > > Well, that's the problem then.  I only discarded the event I was looking
> > > for. So we should flush the queue while checking.
> >
> > More precisely, events shouldn't be queued unless they are enabled by
> > the window's event mask (certain events, e.g. ClientMessage, don't
> > have a corresponding bit in the event mask, and are always reported).
> >
> > Note that the event mask should be checked at the point that the event
> > (message) is queued (generated), not at the point it is dequeued (e.g.
> > by XNextEvent).
> >
> OK.  This seems quite different than what the program was doing.  So to make
> sure I understand, X applications always send a mask when then expect
> something. The server can decide what to do with any events that the
> application hasn't asked for, by way of the mask, as long as they are events
> which are in the mask.  If these aren't within the mask, then send them on
> to the application.  If they are within the mask structure but not part of
> the mask sent by the application, presumably they can be discarded.

Not really. More details (greatly simplified; aspects which don't
apply to XDRIVER or libW11 have been omitted):

1. A window's event mask is initially empty, unless the the client
specifies the CWEventMask bit in the XCreateWindow() call (XDRIVER
initialises the event mask to StructureNotifyMask).

2. The window's event mask can subsequently be changed with
XSelectInput() or XChangeWindowAttributes() (XDRIVER only uses the
former; each of the Get_location_with_* functions changes it to either
"ButtonPressMask | PointerMotionMask" or just ButtonPressMask for the
duration of its event loop, then changes it back to the default of

3. An Event is only generated (added to the event queue) if the
corresponding bit in the event mask is set, or if the event doesn't
have a corresponding bit (e.g. ClientMessage).

4. A client can examine and/or modify the contents of the queue by a
number of functions. The ones which are used by XDRIVER are:

XNextEvent; similar to Windows' GetMessage:

       The XNextEvent function copies the first event from the
       event queue into the specified XEvent structure and then
       removes it from the queue.  If the event queue is empty,
       XNextEvent flushes the output buffer and blocks until an
       event is received.

XCheckWindowEvent; similar to Windows' PeekMessage with PM_REMOVE, but
allows more control over which event types are checked (uses a mask
rather than min/max values).

       The XCheckWindowEvent function searches the event queue
       and then the events available on the server connection for
       the first event that matches the specified window and
       event mask.  If it finds a match, XCheckWindowEvent
       removes that event, copies it into the specified XEvent
       structure, and returns True.  The other events stored in
       the queue are not discarded.  If the event you requested
       is not available, XCheckWindowEvent returns False, and the
       output buffer will have been flushed.


       The XPending function returns the number of events that
       have been received from the X server but have not been
       removed from the event queue.  XPending is identical to
       XEventsQueued with the mode QueuedAfterFlush specified.

Also, XFlush and XSync have an impact on the event queue under X, in
that they can force events to be transmitted from the server to the
client, but this is unlikely to be relevant for libW11.

In general, the situation is complicated by several issues, which
probably aren't relevant here:

1. Multiple clients can select events on a given window (this isn't
relevant for libW11).

2. Events which aren't enabled in a child window's event mask are
propagated upwards to the parent window, unless this is inhibited by
the window's "do not propagate" mask (this isn't relevant for XDRIVER,
which doesn't have any child windows).

3. The event queue is split between the server and the client (this
isn't relevant for libW11; although some buffering normally occurs,
nothing prohibits the server from sending each event to the client as
soon as it is generated).

Glynn Clements <glynn.clements at virgin.net>

More information about the grass-windows mailing list