[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: about RunLoop, joystick support and so on

From: Richard Frith-Macdonald
Subject: Re: about RunLoop, joystick support and so on
Date: Wed, 14 Feb 2007 17:20:13 +0000

On 14 Feb 2007, at 16:56, Xavier Glattard wrote:

Does it hang when you click the 'Start' button ?


I dont undertstand : it runs fine on my debian system (x86)
An OpenGL problem ?

The animation runs fine ... but menu buttons and other controls stop working.

I've just found this : CFRunLoops/index.html
I didn't read all but this might be the API you are waiting for ;-)

Maybe ...if they have done what we want in CoreFoundation they may not be providing any Objective-C (Cocoa) API to do the job. In that case we have to decide whether to add bits of the CoreFoundation API to GNUstep or just stick to our existing API extensions.

That's perhaps a bug ... as I understand it the code it supposed to
return an X or windows event if it has already been received, and if
no event has been received, call the runloop to wait for more
events.  As long as that is working it's fine, but if the attempt to
check for an event already received also does a read to get new
events, then there is indeed the problem you describe of the runloop
never being called.  If this is happening, it's not a bug in the
runloop, just a subtle bug in the backend (in that it is failing to
run the runloop when it should).  Such a bug ought to be fairly easy
to fix ... a crude fix would be to run the runloop once  before
fetching each item from the windows message queue or X event queue.

No : the problem would then be moved to the runLoop : if many non gui
events occur in the runLoop, gui events would never be handled.

I don't follow that argument ... the gui events and non-gui events would be intermingled, so gui events would be handled.

A more efficient option might be to use different calls to examine
the windows/X event queues (ones that don't read in new events), or
to count the events available each time the runloop signals event
availability, and re-run therunloop after the count of events has
been processed.

IMHO the best option would be to manage all events (gui and non gui)
in one place, saying the runLoop. One loop could be :

 - for each source of events : get one event if available (not wait)
 - if there is no event, wait (until a timer fires)
 - sort the events in a queue
 - return the oldest event

This mechanism would need an other queue in the runLoop (or one more
queue for each mode ?). May be they already exist (?)

The runloop works like this ...

1. fire timers and find the ext timer in the future
2. call select()/poll() to wait for the set of all events we are interested blocking until there is an event or it's time for the next timer to fire 3. when that system call returns, call the callback methods for all the objects interested in any of the events found
4. optionally, go back to (1)

So no queue is required by the runloop, it always dispatches all the available events when it is run. It can also be told to run through once without blocking ... that has the effect of firing all the timers and dispatching any events which are immediately available.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]