[Pythonmac-SIG] Weird Carbon: gestalt: wxPython issue/bug

[Christopher Barker]

has wrote:
> Is wx/Mac not already built upon Carbon/Cocoa APIs?

umm -- I'm not sure what that means... anyway:

The current wxMac is built on Carbon. The "unstable" version is built on 
Cocoa. The Cocoa version does not yet have wxPython bindings, and I'm 
not sure when it will be considered production ready/stable. But it will 
have to get there, as we all know that Carbon has been deprecated. So, 
for now, Carbon has to work, but in the future (for Python 3, for 
example), Cocoa-only is the way to go.

 > Cocoa's GUI APIs
> certainly aren't thread-safe - all calls must go through the main
> thread - and I doubt Carbon's GUI APIs are any different.

Well, we need to be clear about what thread-safe means. None of the wx 
back-ends are thread safe, I don't know if any GUI toolkit is -- it 
would be nice, but I guess it's just too hard. However, with wx, 
not-thread-safe means that all call must go through the SAME thread, 
which may NOT be the MAIN thread.

This is very useful for things like iPython, that let you run an 
interactive interpreter in the main thread, and all the gui calls are 
run in another (but all the same one) thread, so you can have an 
interactive interpreter, and GUI display. This is great for doing 
interactive plotting with matplotlib, for instance.

Do you really think that Cocoa does not support that? I know there is a 
Cocoa back-end for Matplotlib, though I don't know for sure if anyone is 
using with with iPython.


 > I think the only sensible solution is to
> rework his application code to ensure all GUI calls are made on the
> main thread,

I don't know why Peter is not running his GUI on the main thread, but as 
I've explained above, there are reasons not to.

If Robin Dunn is right, then a call to gestalt() is initializing enough 
of carbon in the main thread to break things later. This call wx made 
through platform.mac_ver, which was called by something in setuptools, 
which the OP has little control over. It seems to be that there should 
be a way to find out about the platform you are running on without 
initializing the GUI.

> Python's Carbon modules are deprecated in 2.x and gone in 3.x, so its
> Carbon.gestalt module is a dead end for Python users.

and yet that is what is being called by platform.mac_ver(), and thus by 
setuptools. Hence the problem.

> Mac OS X's gestalt APIs are not deprecated, however,

Then those should be used by platform.mac_ver

Ronald Oussoren wrote:

> This means that creating the GUI in a secondairy thread may be safe
> for wx/Carbon, but will definitly break in wx/Cocoa.

ouch! really? That is a major limitation -- are you sure that "main 
thread" really means main thread of the application, rather than "the 
thread the Cocoa was initialized in?"

> I will remove the offending gestalt call for 2.7 and 3.2 because the
> result isn't used on any supported platform. I might backport that
> change to 2.6 and 3.1.  The gestalt bindings won't go away.

Does this mean that you'll use the native OS-X gestalt calls, rather 
than the Carbon ones? Wouldn't that be required for 64 bit to work, anyway?

That would be great, and, I think, solve the problem at hand. We'll have 
to see about wxCocoa....

Thanks,
   -Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov