Re: [Pyobjc-dev] PyObjC and OSX versions

[Ronald O. <ron...@ma...>]

On 30 Mar, 2010, at 21:33, David Bolen wrote:

> Ronald Oussoren <ron...@ma...> writes:
> 
>> NibClassBuilder shouldn't be used in code that's developed on OSX
>> 10.5 or later, the latest tools no longer generate the metadata that
>> is used by this module.  Futhermore Xcode on OSX 10.5 or later knows
>> enough of Python and PyObjC to take away the need for
>> NibClassBuilder.
> 
> Hmm - it sounds like you're saying not just take away the need for but
> preclude the use of.  I assumed that if I'm developing on 10.5, but
> still using PyObjC 1.4 to target a 10.4 client that I still need to
> use the older approach and include NibClassBuilder.

You don't. NibClassBuilder is just a nifty trick to avoid having to define classes, outlets and actions manually in two places. On OSX 10.4 Interface Builder doesn't know anything about Python, which means you have to declare all classes you want to use in that version of IB inside the NIB file.   NibClassBuilder.AutoBaseClass is magic base class that reads information about the class from the NIB file and sets up the right superclass and outlets (as defined in the NIB).

In OSX 10.5 (or later) Interface Builder does know how to read Python files, which means you can define the classes in Python and read the definitions in IB. IMHO that results in much easier to understand code because you don't have to hunt down information when you read the code.    

As an additional snag (sp?) IB on 10.5 won't even create the file that NibClassBuilder uses to determine the superclass and outlets, which means that NibClassBuilder cannot work there.   IB might write the additional metadata when you use .nib files instead of .xib files on OSX 10.5, but both will be compiled to a more compact .nib file by Xcode when you build the application bundle.

Note that all of this is just a matter of developer convenience: if you want to develop on both platforms you can always define the classes both in IB and the python code. That works just fine, but means you have to do a little more work when changing classes.

W.r.t. 10.4 support in general: I'd say that it is more worthwhile to work on porting PyObjC 2.2 to 10.4 than to try to create a workflow using both PyObjC 1.4 and 2.2.   For the most part this entails adding #ifdef guards in the C modules to ensure that the wrappers for APIs that aren't available on 10.4 get excluded from the build when building using the 10.4 SDK.     

Ronald