[Pythonmac-SIG] Non-obvious Question about PyObjC and Xcode

Daniel Lord daniel at brightfire.com
Fri Feb 3 06:31:16 CET 2006


I am a neophyte when it comes to Cocoa and ObjC so forgive me if his  
question is nonsensical and the answer is obvious to you seasoned  
professionals. I decided to tackle a formidable task: learning Cocoa  
and Objective-C by approaching them through Python and Perl which I  
know and find better 'RAD' tools (though I do know C and C++ and have  
written some small Carbon applications using XCode and Code Warrior  
in the past). So I face a steep and formidable learning curve akin to  
soloing the Eiger in Winter perhaps. But here goes...

I have to say I am a bit confused on the two very different sets of  
directions for using PyObjC and I want to use the tools a formal way  
to avoid as much obsolescence of my projects as possible:

1. The Tutorials on the SourceForge site present a somewhat  
traditional way of creating outlets and actions and linking them to  
an instantiated class in Interface Builder before executing py2app.  
However, unlike using the Camel Bones Perl ObjC Bridge, I have to run  
the external build tool outside of Xcode to make a build. I find the  
Camel Bones method much easier and it almost tempts me to go back to  
using Perl over Python (I said _almost_ ;-) $$$$$This means that once  
py2app is  run though, I cannot change my nib files because the  
outlets and actions won't be 'bridged' or will they?

2. The Apple documentation describes an entirely different process  
which involves the Bindings tab of the Inspector in Interface Builder  
and I don't really understand it very well. What confuses me is this:  
1) are they two different methods of achieving the same end and  
eventually will coalesce into some standard that fits Xcode better or  
2) are they instead stark differences in philosophy and underlying  
architecture in accessing the PyObjC Bridge which will stay diverged  
with one eventually obviating the other?

The advantage of the Apple-documented way is that I can use Xcode for  
building the application which is very convenient and consistent but  
I don't really 'get' the Binding tab just yet since I would think  
that it would show the bindings I make the traditional way with the  
Control-click graphic connections if the underlying architecture is  
consistent--and it doesn't. So they seem mutually exclusive and not  
consistent in Xcode. That worries me frankly--it makes them both seem  
more like hacks. It seems to be one way or another.

I find this 'schizophenic' approach to development tools unsettling  
and it concerns me that I risk very fast obsolescence of my work if I  
pick the wrong build approach. Or worse: that both methods are just  
temporary and will disappear capriciously one OS revision without  
warning.So it begs the question: which method will be the 'main- 
stream' recommendation going forward? The SourceForge team is clearly  
a standard-setter but then again Apple has 'vendor power' when it  
comes to Cocoa and Objective-C. The Apple way is far better  
integrated with Xcode but seems strained and awkward when creating  
the outlets and actions because it doesn't use the 'standard' that  
Objective-C/Cocoa projects use and all the Cocoa tutorials use..

Or am I just confused because Cocoa and the Apple Tools  is fairly  
opaque to me at this point?



More information about the Pythonmac-SIG mailing list