Re: Peeking into the event queue?

[Ian Britten <britten universal ca>]

On Mon, 14 Aug 2000, Jon Trowbridge wrote:

> Call this periodically from inside of your loop, and you won't hangg
> the GUI for the duration of your computation:
> 
>   while (gtk_events_pending())
>     gtk_main_iteration();
> 
> Have your cancel keypress callback just set a flag, and then check for
> that flag after the above while() loop.

Thanks for the suggestion, but this isn't a plausable solution for my
particular problem.
The problem is that the above solution is _dispatching_ the events in the
queue, which is exactly what I _don't_ want to do.  (If you're familiar
with XCheckIfEvent(), it doesn't actually dispatch the events, but merely
scans the queue to see if a match exists).

The reason it's a problem is kindof long-winded, and I'll describe it
below for anyone that is interested, but basically, the app is in a
certain state when the idle event starts, and this state shouldn't change
while executing the code (or Bad Things may happen).  If I dispatch the
events, then the state may change, causing problems.  All I want to do is
see if I need to stop processing, and leave the 'normal' event handling
code to handle the events.

<DETAILS>
Our app is drawing a whole bunch of data.  The way it's set up is that one
piece of data is drawn in each idle event.  This way, all the normal
mouse/keyboard handling is cleanly handled elsewhere.
This works fine, unless the object being drawn is large and complex.  If
it is, the user may want to cancel the draw (Esc).

When the draw starts, lots of stuff gets set up, such as viewports,
etc.  These things don't change when an object is being drawn.  If these
settings are changed (ie. The user pans by hitting the arrow key), then
the current draw is stopped (by removing the idle handler), and a new one
is started.

If I dispatch events while drawing the large object, then I may dispatch
an arrow key (for example), which would do a pan operation, changing the
viewport settings, etc.  Control would then return to the (above) loop,
where the draw would continue, using settings that are no longer correct.

What I need to do (and what I do in X), is simply see if the Esc key was
pressed.  If so, the draw stops.  (OTOH, if the arrow key was pressed,
then the object finishes drawing, and the event handler that picks up that
key press will pan and restart a new draw operation).

That may not be completely clear, but it's a large, cross-platform event
handling solution that we have, and this is the only piece that GTK seems
to be missing...
</DETAILS>

Again, thanks for any/all suggestions...
Ian