On 03.09.2008, at 18:36, Berk Özer wrote:
At one point, my application blocks the runloop and I have to poll for mouse events by calling [NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]. I'm not happy with the polling. It seems to me that creating a separate thread and configuring its runloop to process the events I'm interested in (specific mouse events for a specific window) is a more elegant solution. I couldn't find any example code doing that. I suspect that it's not possible for third-party developers to tap into the event stream coming from the window server, to create a CFRunloopSource similar to the one that feeds the main runloop.
You can't really do that, because the GUI should always be driven from the main thread. Few parts of the GUI are thread-safe. Why do you have to block the runloop anyway? Have you thought about doing your work asynchronously or even in a second thread, and only doing the actual event handling and redraws in the main thread?
PS - please do not reply to existing threads and change the subject line to create a new posting. That will sort your message under that old, completely unrelated thread in threaded view in most mail applications. Create a new message instead.
Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
