On 8 May 2009, at 11:00, pythonmac-sig-requ...@python.org wrote:
Send Pythonmac-SIG mailing list submissions to
pythonmac-sig@python.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/pythonmac-sig
or, via email, send a message with subject or body 'help' to
pythonmac-sig-requ...@python.org
You can reach the person managing the list at
pythonmac-sig-ow...@python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pythonmac-SIG digest..."
Today's Topics:
1. Re: Using AHRegisterHelpBook (has)
2. Leaning PyObjC (Kevin Walzer)
3. Re: Leaning PyObjC (Bill Janssen)
From: has <hengist.p...@virgin.net>
Date: 7 May 2009 19:13:36 BST
To: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Using AHRegisterHelpBook
Ronald Oussoren wrote:
Another option is PyObjC, it definitly allows you to integrate with
the native Cocoa help API's.
Out of interest, does PyObjC play nicely with wxPython/Tkinter?
You obviously can't mix GUI toolkits but you can use other PyObjC
API's with Tkinter and wxPython. However the GIL needs consideration.
Also I found some of the older bridging API's defunct when I tried to
use them, particularly quicktime.
But it has been a while since I looked at this.
A further option, if it hasn't already been suggested, would be to
call AHRegisterHelpBook directly via ctypes. Just because Python's
Mac modules have all been deprecated and removed doesn't mean that
all of the underlying OS X APIs have done the same. Some have (e.g.
QuickTime, QuickDraw, and anything GUI-related are best avoided) but
others are still fully supported.
Or, if futzing with ctypes is too much hassle, consider grabbing the
source for the Carbon.AH extension and repackage it as part of the
project. This is what I did with Carbon.AE when developing
appscript, for example.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
From: Kevin Walzer <k...@codebykevin.com>
Date: 7 May 2009 22:53:53 BST
To: pythonmac-sig@python.org
Subject: [Pythonmac-SIG] Leaning PyObjC
Reply-To: k...@codebykevin.com
Hi all,
What's the current "best practice" for learning PyObjC? I've been
developing in Python/Tkinter for quite some time, and I've learned
enough Objective-C/Cocoa to create a small extension that calls into
some Cocoa methods (it's actually a Tcl extension that I can call,
via Tkinter, to change my app's dock icon). I'm planning to work
through some samples in the latest Hillegass book to get familiar
with the full Cocoa toolchain, i.e. Xcode, IB, etc.)
I'm finding myself a bit lost, however, in how to download, build,
and play with PyObjC itself. Based on what I've gathered from the
PyObjC site, I can do the following:
1. Download version 2.0 from SVN or use easy_install 2.2b.
2. Build as outlined in the instructions.
3. Follow the "Creating your first PyObjc application" tutorial,
which requires PyObjC 1.3.1.
I'm especially curious about the tutorial--is it up to date? I've
read a lot about changes between PyObjC 1.x and 2.x, but it's not
clear to me what those changes are. I do know that the differences
between older Cocoa tutorials (pre-Leopard) and new tutorials are
big enough to make it hard to learn from the old ones, owing
especially to big changes in Interface Builder.
My strong preference is to keep my Python toolchain reasonably close
to what I'm doing already, i.e. doing my development outside of
Xcode and using py2app for bundling, rather than using Xcode.
Does this sound like a good approach, or am I missing something
glaringly obvious? What do others who are shipping PyObjC apps do?
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
From: Bill Janssen <jans...@parc.com>
Date: 7 May 2009 23:24:21 BST
To: k...@codebykevin.com
Cc: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Leaning PyObjC
Kevin Walzer <k...@codebykevin.com> wrote:
My strong preference is to keep my Python toolchain reasonably close
to what I'm doing already, i.e. doing my development outside of Xcode
and using py2app for bundling, rather than using Xcode.
I found crossing this bridge a bit tricky, until I embraced Xcode.
Start a Python-Cocoa project with Xcode. Look at the framework it
builds for you. Go on and edit your app delegate, not necessarily
using
Xcode. Hit the "Build and Run" button in Xcode. See what happens.
Repeat.
After you've successfully built a couple of Python apps this way,
you'll
be better prepared to get into the whole py2app thing. The major
problem there is that the folks who build and maintain it are
overworked, and have little to no time to update documentation. So
there are lots of out-of-date documentation pages and examples, which
will mislead you mightily unless you have some other grounding to fall
back on to see if they make sense.
Even then, I have to admit I still don't know how to build a
PreferencePane from scratch. I've got one working, but I had to take
the example, and hack it into shape.
Oh, and read Will Larson's series:
http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/
all the way through.
Bill
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
