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

[Joe L. <jfl...@dg...>]

Hi,

Ok, I think I have a basic understanding of most of the issues but don't 
hesitate to correct any misunderstandings etc. (or terminology) - I'm 
pretty unfamiliar with Tcl/Tk from either from the scripting or 
(especially) the internals side.


On Monday, March 4, 2002, at 01:39  PM, Jim Ingham wrote:

> 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.
>

Regarding the latter (app control of the event loop), it sounds like 
there are two classes of this problem:
     One, where an app/library/extension calls Tk_Main() and provides 
it's *own* event loop, keeping Tcl/Tk spinning by calling 
Tk_DoOneEvent() regularly and and one where an app/lib/extension wants 
to use Tcl/Tk's main event loop but needs to vector into it somehow.

It *seems* to me that Tcl/Tk intends to explicitly support the first 
case (if I recall it says in the docs somewhere that this is why 
Tk_DoOneEvent() exists/is exported).  In its current form, Tk/Aqua 
doesn't seem to fully support this - if I understand correctly, it'll 
only work for an app that doesn't have its own UI events (e.g. it can't 
have its own windows).  I believe this *does* work on Windows and 
X11/unices.

The second case seems to be functionality that isn't explicitly intended 
to be supported by Tcl/Tk (but maybe should be), though depending on the 
particular Tcl/Tk implementation there might be a way to do it.  I don't 
know if this currently even works on Windows or X11/unices (sorry I 
haven't been able to find the old discussions you referred to yet to get 
caught up on what QuickTimeTcl and others require and why).


> 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.
>

Will this work if the app/framework is Cocoa-based as well? (in this 
case, I'm interested in combining Tcl/Tk with GLUT, which seems to be 
implemented using Cocoa events).

It seems that the "ideal" behaviour of Tcl/Tk would be to somehow only 
pull the events it knows belong to it out of the queue (or similar 
functionality, whatever the particular mechanism) and leave the other 
events in the queue for the OS to dispatch via whatever mechanism(s) it 
would if Tcl/Tk weren't around.  Is this possible on OS X? (is it in 
Windows and/or X11?)



> 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...

I'm not sure I fully understand this part.  In particular, are the 
low-level and synthetic events you're talking about internal Tcl/Tk 
events or OS events and is the funky synthetic event handling in Tck/Tk 
or in the OS.



>
> 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.

This would require explicit registration for notification from Tcl/Tk 
right?  That might be livable - when (for example) you create a window, 
you might also call something to register your handler(s) for it.  You 
might even be able to wrap this semi-automatically.  Would this work for 
Cocoa apps/frameworks though? (since their event handling/dispatch seems 
more out of the user's control)



>
> 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 seems to be what Tcl intends to allow explicitly (and if I 
understand, seems to be possible without additional APIs on Windows and 
Linux).  I'm happy to be corrected here though.


>
> 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.

This is the part that it seems to me that Tcl doesn't explicitly support 
(but that there may be a way of doing in given implementations).



>
>>
>> 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!

I tried to find these but I wasn't able to - is there a way to search 
the tcl-mac mail archives?  All I can find thus far are at (maybe this 
is because sourceforge is down right now?):
   http://www.geocrawler.com/lists/3/SourceForge/7933/0/

Thanks a lot for the info/feedback.  I'm definitely interested in 
getting the first class of functionality I mentioned (spinning Tcl/Tk's 
event loop explicitly myself) if that's possible, with the hope that 
it'd work with Cocoa frameworks too.  Having to use some API to set it 
up seems reasonable enough if it works.


Cheers,
Joe.