On 04.09.2008, at 17:04, Benjamin Stiglitz wrote:
This isn’t really polling as much as taking over the runloop and
filtering out some events. There’s nothing really inelegant about
this—it’s the call that powers the tracking loop in most of the
controls in AppKit. If you really wanted, you c
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'
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-saf
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
confi
Hi all!
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
