[mac-lisp-ide] Re: ideas and issues

[Duncan Rose]

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
>