[ < ] | [ > ] | [ << ] | [ 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.