Re: Progress gauge weirdity
At 12:10 AM 3/23/00 -0700, Ben Wing wrote:
I'm very confused. The SIGIO timer is used *only* for C-g. It
has
nothing to
do with any other events.
You're right. However,
(sit-for 0) ought to
(1) cause all pending non-command events to get executed, and
(b) do redisplay
This does not do what I need for two reasons:
1. sit-for will simply return if there are command-events in the queue.
This does not run redisplay and more importantly does not return control to
the Xt event loop which is required for native widget updates.
2. sit-for does a full redisplay which is too agressive (and slow) for the
progress gauges and gutters. I need to only redisplay the gutters a bit
like redisplay-echo-area (that's why redisplay-gutter-area exists).
1) is the killer. The ways round this are:
call next_event_internal but this will block if there aren't actually any
XEmacs targeted events pending. The way round this is to schedule a wake-up
or simply post a dummy event that will guarantee to cycle the event loop. I
do the latter. My mistake with SIGIO was that event_stream_event_pending_p
(1) will only consult the Xt event stream if SIGIO says something has
happened, so I fake this. The alternative is probably just to pump a dummy
event and call next_event_internal.
However, sit-for gets preempted by input coming in.
What about (sit-for 0.1)?
Again, redisplay is too agressive and input - even pending input - will
pre-empt.
I suppose a solution along the lines of dispatch-non-command-events
might
be OK
if you've tried everything else and it doesn't work, but
i'm leery of
introducing new Lisp functions to deal with specific problems. Pretty
soon we
end up with a whole bevy of such ill-defined functions, like we
already have.
I think instead, you should introduce the following primitive:
(wait-for-event redisplay &rest event-specs)
Waits for one of the event specifications specified to happen. Returns
something about what happened.
REDISPLAY controls the behavior of redisplay during waiting. Something like
nil (never redisplay),
t (redisplay when it seems appropriate), etc.
EVENT-SPECS could be
t -- drain all non-user events, and then return
any-process -- wait till input or state change on any process
process -- wait till input or state change on process
time -- wait till such-and-such time has elapsed
'user -- wait till user event has happened
'(user predicate) -- wait till user event matching the predicate has
happened
'event -- wait till any event has happened
'(event predicate) -- wait till event matching the predicate has happened
The existing functions `next-event', `next-command-event',
`accept-process-output', `sit-for', `sleep-for', etc. could all be written in
terms of this new command. You could use this command inside of your glyph
code to ensure that the events get processed that need do in order for widget
updates to happen.
This might be ok. I'm not sure that I actually need to dispatch non-command
events at all, I just need to make sure that the Xt event loop gets cycled.
But you said something about need a magic event to invoke redisplay?
Why is
that?
See above.
I also don't understand what you say about "exiting the event
loop". I
wonder
What I mean is getting into the guts of the Xt event loop. XEmacs won't do
this unless is sees a need to. "need to" means there is nothing else to do
or someone pressed ^G.
if perhaps you don't completely understand how the XEmacs event
loop works?
:) Does anyone?
Point me to the section of the widget code that deals with events, and
I'll try
to look at it and see if I can figure something out; I'm almost
certain i can
come up with a better way of doing things.
There is no such section of code because what we are talking about is
events handled natively by other widgets.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd