[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated using texi2html 1.76.