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

[Ronald Oussoren]

On 3-feb-2006, at 6:31, Daniel Lord wrote:

> 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 learned Cocoa while rewriting PyObjC :-). Cocoa isn't very hard,
the hard part is deducing how the framework designers want you to write
code. Cocoa is one of those "if it is hard you're doing it the wrong  
way"
frameworks.


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

No, the tutorial presents an easy way to generate the initial  
implemention
of the classes you defined in the nib file. If you change the nib you'll
have to change your sources by hand, no need to rerun tools again.

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

Cocoa bindings are a method for reducing the amount of code you have
to write in your controller layer in a MVC design. PyObjC fully supports
this, and there are even examples that show you how.

The major disadvantage of bindings is that this makes it harder to how
a program works, you can't just print out source code and find a quiet
space to digest it but part of you logic will be in the nib file. But
the big advantage of bindings is that you'll have to write less code,
and hence have less change to make bugs. I'd say the advantage is larger
than the disadvantage.

However, if I were new to Cocoa I'd start by ignoring bindings  
because that
makes it easier to get a feel of framework.

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

Bindings are the way forward, but build on the older behaviour. There is
little change that the older behaviour will go away.

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

Ronald
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060203/79a05bd5/attachment.bin