On Jan 31, 2004, at 11:19 AM, Duncan Rose wrote:
On Saturday, January 31, 2004, at 12:23 AM, Timothy Moore wrote:
The main issue is that window system events are delivered only to the main thread and really have to be handled there too. AIUI.
I'm not sure what AIUI means 8-) And I'm also not sure in this context what "window
"As I Understand it"
system" events means... but under the assumption we're talking about any events generated by the window system, I think that these events get delivered to any thread that is running an event loop (i.e. that has an executing run loop). I'll talk about this a little more since I now consider we're back on topic for any threaded GUI work in Cocoa, which will include any IDE we write irrespective of whether it uses CLIM.
I'll split the events into "send to object" and "send to thread" events. Many mouse events (mouse left / right / other down and up, scroll wheel, drag events) are sent directly to the NSView over which they occurred, irrespective of the thread in which they are running and irrespective of whether that thread has an executing run loop. My experimental back end already responds to those (although I am only passing mouse down / up events onto the rest of McCLIM at the moment).
Perhaps I need to go back and review Cocoa a bit. What does it mean for an NSView to be "running in a thread?" What you say about events being sent directly to the NSView fits with my understanding of the situation i.e., the method that handles the event for the NSView runs in the thread of the main event loop.
The thing I'm not clear on at the moment, but that I hopefully will be sure about in a couple of days, is a) whether this works at all 8-), and b) whether this can cause events to be passed to multiple handlers (e.g. if my NSView or NSWindow is tied up being drawn when key events arrive in the window server queue, will the main threads run loop get to pull them off the queue before the run loop I started for the thread managing the view / window can do so? Or can *both* run loops consume the event (sounds dodgy if so). Or is the event handling in Cocoa clever enough to know that the thread in which the window / view is running has a run loop started, and ensure that only it gets those events?
Same question, what is "the thread in which the view is running?" I wouldn't assume it's the thread that creates the view or that has the focus locked or whatever.
Tim
On Sunday, February 1, 2004, at 08:32 PM, Timothy Moore wrote:
.snipped.
I'll split the events into "send to object" and "send to thread" events. Many mouse events (mouse left / right / other down and up, scroll wheel, drag events) are sent directly to the NSView over which they occurred, irrespective of the thread in which they are running and irrespective of whether that thread has an executing run loop. My experimental back end already responds to those (although I am only passing mouse down / up events onto the rest of McCLIM at the >> moment).
Perhaps I need to go back and review Cocoa a bit. What does it mean for an NSView to be "running in a thread?" What you say about events being sent directly to the NSView fits with my understanding of the situation i.e., the method that handles the event for the NSView runs in the thread of the main event loop.
The thing I'm not clear on at the moment, but that I hopefully will be sure about in a couple of days, is a) whether this works at all 8-), and b) whether this can cause events to be passed to multiple handlers (e.g. if my NSView or NSWindow is tied up being drawn when key events arrive in the window server queue, will the main threads run loop get to pull them off the queue before the run loop I started for the thread managing the view / window can do so? Or can *both* run loops consume the event (sounds dodgy if so). Or is the event handling in Cocoa clever enough to know that the thread in which the window / view is running has a run loop started, and ensure that only it gets those events?
Same question, what is "the thread in which the view is running?" I wouldn't assume it's the thread that creates the view or that has the focus locked or whatever.
That's a good question. I had assumed it was the same thread that ran the (in this case) listener application - since that's the thread that constructs the windows and sends the messages to put them up on the display. Theoretically, this thread shouldn't be handling events (at least by my understanding of a couple of days ago) but it seems that it is. Or that the views are in fact running in a different thread.
Whether I need to differentiate between receiving events, distributing events, and handling events in this I'm not sure.
I thought for a while I had this whole event / run loop thing pegged down reasonably well. It appears I was mistaken 8-)
It wouldn't be too hard to insert some debug at a few different places to see exactly what's executing in which thread - and I'm going to do this at some point in the hope of understanding this better.
-Duncan
Tim
-
Duncan Rose -
Timothy Moore