Re: about RunLoop, joystick support and so on

[Richard Frith-Macdonald]

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

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

Yes.

> 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 :
> http://developer.apple.com/documentation/CoreFoundation/Conceptual/ 
> 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.