[Pythonmac-SIG] Carbon GUI/MacPython
Bob Ippolito
bob at redivi.com
Fri Aug 13 06:06:39 CEST 2004
On Aug 12, 2004, at 11:24 PM, Kevin Walzer wrote:
> I'm curious as to why the Carbon side of MacPython doesn't seem to be
> updated, at least with regard to GUI programming. Earlier, when I
> queried the list about the W widget set and some related questions, I
> was advised that these were deprecated and would likely go away at some
> point in the future. It was also mentioned that MacPython (the
> PythonIDE
> and PackageManager) are dependent on the Waste module, which also seems
> obsolete.
W is just *barely* Carbon. It predates Carbon and doesn't do things
the Carbon way (especially wrt. event loops). PythonIDE predates
Carbon too, and PackageManager uses W (I think, anyway). Nobody wants
to work on them because overhauling ancient code isn't very much fun,
neither is working with Carbon.
I'm pretty sure there's a PyObjC replacement for PackageManager
complete or near-complete, and there was a wxPython version of it
floating around a while ago. There isn't an official PythonIDE
replacement yet, but there is PyOXIDE (written mostly(?) in ObjC,
though).
> My question is, what's going to replace these things? The Carbon API
> has
> more modern text processing facilities than Waste (MLTE?), if I have
> read the documentation correctly, and one can certainly also call the
> complete set of Interface Builder widgets from Carbon. Or is PyObjC
> going to become the "official" Mac-native API for Python at some point
> in the future--the only way to write Python software that takes full
> advantage of Mac API's?
The Carbon modules are there, and you can use them. I'm not sure about
completeness or correctness, but it's automatically generated from the
headers. I know from experience that this sort of automatically
generated wrapper generally isn't going to be very good if people don't
test it (like the Quicktime wrappers, for example). These sort of bugs
are pretty easy to fix (for Jack, anyway), so if you try something that
doesn't work and report a bug it will probably get fixed eventually.
The question is WHY you would choose Carbon over Cocoa? Have you tried
directly using both?! I would say that PyObjC is already more or less
the 'official' way to get at Mac-native APIs from Python. If not now,
then it will be soon enough.
> I'm just trying to figure out where I want to focus my investment of
> time in learning Python GUI programming on the Mac. I'm working with
> Tcl/Tk Aqua right now, but Tkinter gets such a bad rap on this list,
> anyway, and it seems pretty clear that PyObjC (and wxPython) are richer
> toolkits overall. I'm just more interested in Carbon than Cocoa at this
> point (I do like AppleScript Studio, but it abstracts the Cocoa stuff
> in
> a way that is easier for me to learn than ObjC looks), and curious if
> there's any future in Carbon-specific GUI programming with Python. I
> certainly don't want to waste time learning an obsolete and
> unsupported API.
Support for the Carbon APIs isn't going to go anywhere, but I think
you'll more or less be alone in using them if that's what you choose to
do. I definitely can't imagine anyone actually choosing Carbon over
Cocoa given the choice (no legacy code, no need for OS9, etc.).
-bob
More information about the Pythonmac-SIG
mailing list