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

[Timothy Moore]

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