• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Creating a runloop to handle specific mouse events
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Creating a runloop to handle specific mouse events


  • Subject: Re: Creating a runloop to handle specific mouse events
  • From: Berk Özer <email@hidden>
  • Date: Thu, 04 Sep 2008 12:38:45 +0200

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 (email@hidden)

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:
This email sent to email@hidden


References: 
 >nibless applications (From: David Alter <email@hidden>)
 >Re: nibless applications (From: Filip van der Meeren <email@hidden>)
 >Re: nibless applications (From: Jeff Johnson <email@hidden>)
 >Creating a runloop to handle specific mouse events (From: Berk Özer <email@hidden>)
 >Re: Creating a runloop to handle specific mouse events (From: Uli Kusterer <email@hidden>)

  • Prev by Date: Re: NSPanel: resigning key focus?
  • Next by Date: (no subject)
  • Previous by thread: Re: Creating a runloop to handle specific mouse events
  • Next by thread: Re: Creating a runloop to handle specific mouse events
  • Index(es):
    • Date
    • Thread