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

[Bob Ippolito]

On Feb 2, 2006, at 9:31 PM, Daniel Lord wrote:

> 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:

There are two supported ways to use PyObjC in combination -- with and  
without Xcode.  Using Xcode is somewhat better for prototyping, not  
using Xcode is better for compatibility and version control (since  
the Xcode version needs to muck about reading the Xcode project file  
in order to get the information it needs).

> 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?

PyObjC ships with an Xcode template which will run py2app for you, so  
there is effectively no "external build tool" you need to worry about  
if you take that approach.

Nib files and py2app are totally unrelated.  With py2app's alias  
mode, you don't even need to run py2app again when you *change the  
source code*!

> 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.

Bindings and Outlets/Actions are two different things, but there's a  
lot of overlap in what they can do.  Bindings are new in Mac OS X  
10.3, and PyObjC is a lot older than that.

> 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?

You're confused for a lot of reasons...

Whichever APIs you use, you don't have to worry about forwards  
compatibility.  Nothing that Apple does with regard to their APIs are  
temporary.  They almost never break any API that used to work, but  
they will shove deprecation warnings down your throat at compile time  
(and sometimes runtime in the console log).  For example, lots of  
code from the early 90s from an entirely different flavor of Mac OS  
still compiles if you prod it a little (change the header files to  
Carbon, etc.).

Nothing that Xcode does is special (except ZeroLink, I guess, which  
isn't relevant).  All the functionality in Xcode lives somewhere in a  
unix tool or in a Cocoa API.  It's "just" a pretty face on stuff you  
can do by other means.

Interface Builder is a separate application from Xcode.

Bindings and Outlets/Actions aren't mutually exclusive.

Every technique that can be used with Cocoa is applicable to PyObjC,  
so basically any Apple tutorial for Cocoa/Objective-C is going to  
work with PyObjC given that you know how to translate the syntax and  
build instructions appropriately.

-bob