[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ] [ Search: ]

6.1.1.2 Run-Loop

The typical Crystal Space application assumes that the programmer has full control over the application's run-loop. For many platforms to which Crystal Space has been ported, this is not a problem since the main run-loop is generally implemented in this fashion:

 
bool csDefaultRunLoop(iObjectRegistry*)
{
  while (!shutdown)
    event_queue->Process();
}

With Cocoa, on the other hand, the main run-loop is not accessible to the programmer and is essentially a black-box. A simple-minded implementation of the above functionality for Cocoa might look like this:

 
bool csDefaultRunLoop(iObjectRegistry*)
{
  [NSApp run];
}

This code launches the Cocoa run-loop but does not address the problem of periodically processing Crystal Space's event queue. To solve this problem ‘OSXDelegate’ artificially injects application-defined events into the Cocoa event queue and then triggers an invocation of iEventQueue::Process() for each such received event. A single application-defined event is injected into the event queue in order to begin the process, and then an event is injected into the queue after each invocation of iEventQueue::Process().

Note that csDefaultRunLoop() is provided as a convenience for applications which do not otherwise supply their own run-loop. Existing Cocoa applications which already employ the NSApplication's black-box run-loop should not invoke csDefaultRunLoop(); but should instead arrange to have iEventQueue::Process() invoked on a periodic basis via some other mechanism.


This document was generated using texi2html 1.76.