On Wednesday, December 4, 2002, at 04:15 AM,
pyt...@py... wrote:
> If you are developing a turnkey application I think I would suggest
> PyObjC. It can build on the installed /usr/bin/python, and an
> application in PyObjC will fit all your requirements (possibly with
> the exception of the 2MB download, I'm not 100% sure of that).
> Building a fullblown application with PyObjC still has a few rough
> edges, but they're being ironed out quickly.
As Jack mentioned, there are a couple of rough edges, but PyObjC is
definitely a viable means of building standalone GUI applications
targeted to MacOSX in Python.
If you do decide to delve deeper into PyObjC, please grab the
source/examples/etc from pyobjc.sourceforge.net. The current
repository contents is way better than the last released version-- many
bug fixes, many enhancements to make the programming experience
considerably easier and more powerful. Ronald Oussoren has made the
interaction between ObjC and Python significantly more seamless and
bullet proof than the last release; he has gone so far as to identify
and workaround some very subtle/nasty bugs in certain AppKit classes.
The examples contained in the repository provide an excellent starting
point. In particular, the Web Services Tool and TableModel2 provide
complete examples of building PyObjC applications using Project Builder
as the IDE. There are also examples that demonstrate building
applications without using PB.
Just van Rossum has done an incredible job of providing tools to the
PyObjC project.
In particular, Just contributed a mechanism via which classes defined
in interface files [NIB files] are automatically created when the NIB
file is loaded. That is, the entire step of keeping your source files
in sync with your interface files has been eliminated-- "it just
works". In this context, it is less work to build a PyObjC based
Cocoa app than a Java or ObjC based Cocoa app!
Personally, I'm using PyObjC to build two production quality
applications, one of which is relatively complex [it is really a suite
of applications that share two frameworks -- one framework of which is
almost entirely implemented in Python with a PyObjC bridged layer that
the rest of the app uses]. I chose this route not because I like
living on the bleeding edge, but because using PyObjC cut a huge amount
of gnarly, bug prone, code out of my project and the end result is a
more robust applications that performs every bit as well as a
pure-C/ObjC counterpart. (Specifically, I replaced the entire web
services layer of my application with a python implementation of the
web services client. As an added advantage, my python based web
services client now works seamlessly across all operating systems /
platforms, yet my OS X GUI client remains a pure Cocoa/OS X UI
experience.)
Very cool stuff -- we have come a long, long way since PyObjC '96!
b.bum
|
