Re: [MACTCL] tk/OS X event handling?

[Jim I. <ji...@ap...>]

On 3/4/02 7:44 AM, "Jack Jansen" <Jac...@or...> wrote:

> 
> On Monday, March 4, 2002, at 03:41 , Joe Laszlo wrote:
> 
>> I had the same problems ((Tcl/Tk and GLUT event loops colliding) with
>> Mac OS 9 when I tried porting the same app. there and eventually gave
>> up.  I'm sure it could have been done by modifying both Tcl/Tk and
>> GLUT, but it was just too much effort.
> 
> On Mac OS 9 (with the Classic event manager) it is pretty much
> impossible without the cooperation of the various packages: one of the
> packages will be running ther current event loop with WaitNextEvent and
> it will get all events. If it gets events for windows it doesn't know
> about it has little option but dropping them on the floor.
> 
> With the new Carbon Events things are much brighter. The event loop is
> out of your own control (probably in CarbonLib in OS9 and maybe even
> deeper down in the system on OSX, but this is guesswork) and you
> subscribe to specific events on specific objects. So, all should have
> been hunky dory.
> 
> But (and I'm paraphrasing Jim here, or actually my memory of what he
> said) while this routing all works fine for system generated events it
> breaks down if you want to modify events on the fly. Theoretically you
> can subscribe to a lowlevel event (say, "mouse button 3 press"), convert
> that to something else (say, "mouse button 1 double click") and
> re-insert that in the flow of things. But this apparently doesn't work,
> and Tk needs it. So, Tk has an "old-fashioned" event loop where it
> simply grabs all events and does the dispatching itself. So, foreign
> windows break:-(

There are a couple of different problems here.  One is how to farm some
events off to foreign windows, while retaining all the ones Tk cares about
for itself.  The other is how to give another part of the App control of the
event loop itself some or all of the time.

First, if all we needed to do was send events that belong to a non-Tk window
in the app, that is pretty easy.  We CAN use the Carbon Event system and
just forward events on whatever Carbon Event handler is registered with the
other windows.  That part is fine - and in fact we already do this for the
Nav Services windows that you create with tk_getOpenFile, etc.

As an aside, the problem with Carbon Events was when we tried to use the
Carbon event default handlers to get some behaviors (like generic Window
level behaviors - the title buttons, titlebar dragging, etc).  The problem
with this was that these behaviors are implemented by converting a low-level
event to a synthetic event.  But the synthetic event behavior was odd.
First off, the synthetic events were never posted to the event queue, they
were directly handled.  This really messes Tk up, because Tk's model is that
all native events are converted to Tk events, put on Tk's queue, and then
multiplexed with all the other events that Tk wants to handle back at the
event loop level.  Having 3 or 4 events generated and handled on the stack
sequentially - before we could get back to the Tk event dispatcher -  got
really nasty.  The other problem was that some of the window behaviors were
implemented by NOT handling an event, but by just modifying the event
parameters and sending it on.  This didn't fit the Tk model at all...

So we use don't use any of the standard Carbon Event handlers.  But that
doesn't mean that we can't dispatch events as Carbon events to other
handlers.

The part that I am unsure about is what to do with extensions or other apps
that want to run the event loop themselves.  One solution here is to not use
the Tk notifier, but let the App feed events to Tcl.  This means the app
would have to spin the Tcl part of the notifier (which happens on a separate
thread) and then use the lower level primitives - Tcl_DoOneEvent without
allowing it to wait - every so often to handle events.  I think that we
would have to make some private API's public so you could tell whether Tcl
had handled an event at all.

This would work, and I think the code is pretty well set up to allow you to
do this, though there are some necessary API's that are now private that we
would have to make public...  This is actually the way that sharing the
event loop worked in the Xt case, IIRC.  But this means that

But if you want to use the standard Wish, but need to modally spin the event
loop yourself sometimes, we will have to do some more work to allow this.  I
think this is what Mats' QuickTimeTcl extension needs.  I am less certain
how to do this.  This is an area where somebody just needs to play around a
bit with a concrete example and see what works.

> 
> But please note that all this explaining is based on memory of a
> conversation, not on actual experiments yet, so take it with a grain of
> salt.

Pretty good for a 4 or 5 month old email exchange!

Jim
-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              ji...@ap...
Developer Tools - gdb