It's a big legacy app. Refactoring the blocking routines into separate
threads is major work. So I was wondering if I could kind of reverse
the concept by controlling which events get channelled to which
thread. The rendering functionality of the window server wouldn't need
to be thread-safe. Only the access to the event queue. Of course, I
must not issue any display commands from within the secondary threads.
At the moment, polling works for me. I'm just curious about
alternative solutions.
Regs.
Berk
On Sep 4, 2008, at 10:26 AM, Uli Kusterer wrote:
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]
