As usual, it will probably cause plugin headaches, but I still believe
it's the "right thing to do".
-Brian
Mike Pinkerton wrote:
> Given all the problems that we've had with our open file transport
> counter and chugging down 75% cpu, I've decided to take another look at
> moving our carbon/osx bits to the CarbonEvent model which basically uses
> callbacks to get events instead of polling with WaitNextEvent.
>
> The way our current architecture is set up, the have a "message pump"
> that runs the main event loop. Embedding applications can use ours or
> write their own (i assume they write their own). After some
> preprocessing (closing popups, etc), the event is sent to the message
> sink which then just funnels the event to the appropriate nsMacWindow
> and its internal nsMacEventHandler.
>
> The CarbonEvent model is more window-centric in that you install event
> handlers on particular windows to handle clicks, keys, activates, etc.
> As a result, the most events would go directly to the window registered
> to handle the event and not through a central pump/sink. I believe this
> shouldn't impact embedding for a couple of reasons:
>
> - embedding doesn't have a nsMacWindow (or does it?) where the mouse/key
> the events end up
> - for these kinds of events, the pump/sink machinery is just overhead
> that simply funnels the event into the event handler on a particular nsMacWindow
>
> There is a mechanism to handle events at the application level, and
> that's probably where we'd want to handle timers and some idle event
> processing. I haven't looked too closely into that yet, but I'm pretty
> sure it's nothing complicated.
>
> I really just wanted to throw this out there before I got too far to see
> if anyone (Conrad?) had any serious concerns or objections. I don't want
> to get rid of the pump/sink machinery, only avoid it where advantageous.
> Obviously embedders would still fire events into the sink from their own
> event handlers and so we'd have to make sure to keep the event
> processing separated so it's reusable between the embedded/non-embedded case.
>
> On a side note, should we have a new interface for the message sink for
> carbonEvent-based embedding apps, given that EventRef you get from
> carbonEvent-based apps is opaque?
>
>
--
--
Brian S. Nesse
Mac Browser Repair Technician
Netscape Communications Corp.
