| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The design of Crystal Space assumes that the programmer has full control over the application's run-loop. With most ports of Crystal Space, 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 the AppKit, on the other hand, the main run-loop is not accessible to the programmer and is essentially a black-box. The above mechanism is easily emulated with the AppKit using the following code:
bool csDefaultRunLoop(iObjectRegistry*)
{
[NSApp run];
}
|
This code launches the AppKit's run-loop but does not address the problem of
periodically processing Crystal Space's event queue. To solve this problem
`NeXTDelegate' artifically injects application-defined events into
the AppKit event queue and then triggers an invocation of
iEventQueue::Process() for each such received event. In particular, 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,
OpenStep, and NextStep applications which already employ the AppKit'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.