Re: [MACTCL] tkConfig.sh

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

Jack,

On Monday, October 22, 2001, at 03:27  AM, Jack Jansen wrote:

>> While messing around with Tkinter, I'm having similar problems:
>>
>> Without adding any MacOSX specific code to Tkinter, the window Tk
>> creates never responds to anything. I tried adding what I thought was
>> the relevant code from tkMacOSXAppInit.c(*), and that didn't fix it...
>>
>> So, I tried compiling tkMacOSXAppInit.c alone to see if my problems
>> were in how I was compiling the stuff - basically just did
>>
>> cc tkMacOSXAppInit.c -o a.out
>>
>> with a lot of -I's and -framework's
>>
>> And I got the same behavior! The window did not respond to events!
>> Which leads me to wonder if I have to make a .app and not a plain
>> binary. Jim, does that sound correct? Would the application need to
>> be a .app?
>
> My guess is that the application indeed has to be a .app to be able to 
> handle
> event input. When I tried to put up dialogs from a command-line Python 
> I saw
> the same thing: the dialogs would show, but they would not react.
>

I don't think this is a correct guess.  Most of the Carbon PEF 
applications that run on X don't come in App packages.  And there are 
several command line utilities on X that use Carbon for UI, either to 
put up warning dialogs (some of the installer stuff does this) or to put 
up Authorization panels.

My guess is you are being bitten by Carbon's not playing very nicely in 
a threaded environment (IIRC, Python uses multiple threads).  Unless you 
are willing to go through a lot of pain, if your app is multi-threaded 
you have to be sure to call ReceiveNextEvent, or whatever else you are 
using to fetch events from the WindowServer, on the thread on which 
Carbon is initialized - let's call this the Carbon thread.  It turns out 
that the Carbon initialization generally happens in the dyld init 
routine for HIToolbox, so unless you play around alot with loading 
shared libraries, the Carbon thread will be the main thread of your 
application.
The problem is that ReceiveNextEventis a little more general on Carbon 
than in Classic.  It pulls events off the queue that is associated with 
the current thread - regardless of what the source of events is for that 
thread.  However, so far as I can tell, Carbon only deposits events onto 
the Carbon thread in the application.  So if you call RNE on a 
subsidiary thread, it won't even see any events unless some other thread 
takes them off the main thread's event queue, and transfers them to the 
waiting thread.

This caused us no end of trouble when we were trying to port Tk 
originally.  Maybe this is what is going on?

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer