[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