+static inline bool FakeNeedMoreIdle()
+{
+#if 0
+// Return true on every 10th call.
+ static int idleCount = 0;
+ return ++idleCount % 10;
+#else
+ return false;
+#endif
+}
+
+/*!
+ Called by CFRunLoop just before waiting. This is the appropriate time to
+ send idle events. Unlike other ports, we don't peek the queue for events
+ and stop idling if there is one. Instead, if the user requests more idle
+ events we tell Cocoa to send us an applicationWillUpdate notification
+ which will cause our observer of that notification to tell CFRunLoop to
+ call us before waiting which will cause us to be fired again but only
+ after exhausting the event queue.
+
+ The reason we do it this way is that peeking for an event causes CFRunLoop
+ to reenter and fire off its timers, observers, and sources which we're
+ better off avoiding. Doing it this way, we basically let CFRunLoop do the
+ work of peeking for the next event which is much nicer.
+ */
+void wxApp::CF_ObserveMainRunLoopBeforeWaiting(CFRunLoopObserverRef observer, int activity)
+{
+ // Ensure that CocoaDelegate_applicationWillUpdate will recreate us.
+ // We've already been invalidated by CFRunLoop because we are one-shot.
+ m_cfRunLoopIdleObserver.reset();
+#if 0
+ wxLogTrace(wxTRACE_COCOA,wxT("Idle BEGIN (%d)"), sg_cApplicationWillUpdate);
+ sg_cApplicationWillUpdate = 0;
+#else
+ wxLogTrace(wxTRACE_COCOA,wxT("Idle BEGIN"));
+#endif
+ if( ProcessIdle() || FakeNeedMoreIdle() )
+ {
+ wxLogTrace(wxTRACE_COCOA, wxT("Idle REQUEST MORE"));
+ [NSApp setWindowsNeedUpdate:YES];
+ }
+ else
+ {
+ wxLogTrace(wxTRACE_COCOA, wxT("Idle END"));
+ }
+}
+
+#ifdef __WXDEBUG__
+void wxApp::OnAssert(const wxChar *file, int line, const wxChar* cond, const wxChar *msg)
+{
+ m_isInAssert = true;
+ wxAppBase::OnAssert(file, line, cond, msg);
+ m_isInAssert = false;
+}
+#endif // __WXDEBUG__
+
+/* A note about Cocoa's event loops vs. run loops:
+
+ It's important to understand that Cocoa has a two-level event loop. The
+ outer level is run by NSApplication and can only ever happen on the main
+ thread. The nextEventMatchingMask:untilDate:inMode:dequeue: method returns
+ the next event which is then given to sendEvent: to send it. These
+ methods are defined in NSApplication and are thus part of AppKit.
+
+ Events (NSEvent) are only sent due to actual user actions like clicking
+ the mouse or moving the mouse or pressing a key and so on. There are no
+ paint events; there are no timer events; there are no socket events; there
+ are no idle events.
+
+ All of those types of "events" have nothing to do with the GUI at all.
+ That is why Cocoa's AppKit doesn't implement them. Instead, they are
+ implemented in Foundation's NSRunLoop which on OS X uses CFRunLoop
+ to do the actual work.
+
+ How NSApplication uses NSRunLoop is rather interesting. Basically, it
+ interacts with NSRunLoop only from within the nextEventMatchingMask
+ method. It passes its inMode: argument almost directly to NSRunLoop
+ and thus CFRunLoop. The run loop then runs (e.g. loops) until it
+ is told to exit. The run loop calls the callout functions directly.
+ From within those callout functions the run loop is considered to
+ be running. Presumably, the AppKit installs a run loop source to
+ receive messages from the window server over the mach port (like a
+ socket). For some messages (e.g. need to paint) the AppKit will
+ call application code like drawRect: without exiting the run loop.
+ For other messages (ones that can be encapsulated in an NSEvent)
+ the AppKit tells the run loop to exit which returns control to
+ the nextEventMatchingMask method which then returns the NSEvent
+ object. It's important to note that once the runloop has exited
+ it is no longer considered running and thus if you ask it which
+ mode it is running in it will return nil.
+
+ When manually pumping the event loop care should be taken to
+ tell it to run in the correct mode. For instance, if you are
+ using it to run a modal dialog then you want to run it in
+ the modal panel run loop mode. AppKit presumably has sources
+ or timers or observers that specifically don't listen on this
+ mode. Another interesting mode is the connection reply mode.
+ This allows Cocoa to wait for a response from a distributed
+ objects message without firing off user code that may result
+ in a DO call being made thus recursing. So basically, the
+ mode is a way for Cocoa to attempt to avoid run loop recursion
+ but to allow it under certain circumstances.
+ */
projects / wxWidgets.git / blobdiff