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.bar...@noaa.gov
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
