1. Jeremy Reichman
  2. pyobjc


Ronald Oussoren  committed 7144c7d

- Add wrapper for OSAKit

  • Participants
  • Parent commits db79d28
  • Branches pyobjc-ancient

Comments (0)

Files changed (10)

File Doc/Xcode-Templates.html

View file
 PyObjC Xcode Templates</title>
 <meta name="Author" content="Bob Ippolito" />
 <meta name="Contact" content="bob@redivi.com" />
 <h2>PyObjC Xcode Templates</h2>
 applications &quot;by hand&quot; using py2app, as described in the
 tutorial.  As of PyObjC 1.3.1, these templates are py2app based,
 so there is no longer a technical reason not to use them.</p>
+<table border="1" width="80%" align="center"><tbody><tr><td><i><center>Contents</center></i><br />
-<li><a href="#installing" id="id3" name="id3">Installing</a></li>
-<li><a href="#notes" id="id4" name="id4">Notes</a></li>
-<li><a href="#groups" id="id5" name="id5">Groups</a></li>
-<li><a href="#targets" id="id6" name="id6">Targets</a></li>
-<li><a href="#custom-executable" id="id7" name="id7">Custom Executable</a></li>
-<li><a href="#pyobjc-application" id="id8" name="id8">PyObjC Application</a></li>
-<li><a href="#pyobjc-document-based-application" id="id9" name="id9">PyObjC Document Based Application</a></li>
-<li><a href="#pyobjc-mixed-application" id="id10" name="id10">PyObjC Mixed Application</a></li>
+<li><a href="#installing">Installing</a></li>
+<li><a href="#notes">Notes</a></li>
+<li><a href="#groups">Groups</a></li>
+<li><a href="#targets">Targets</a></li>
+<li><a href="#custom-executable">Custom Executable</a></li>
+<li><a href="#pyobjc-application">PyObjC Application</a></li>
+<li><a href="#pyobjc-document-based-application">PyObjC Document Based Application</a></li>
+<li><a href="#pyobjc-mixed-application">PyObjC Mixed Application</a></li>
-<h2><a href="#id3" name="installing">Installing</a></h2>
+<h2><a href="#id3">Installing</a></h2>
 <p>If you have installed PyObjC 1.3.1 or later using the installer, then
 the Xcode templates are already installed.</p>
 <p>If you have installed any version of PyObjC prior to 1.3.1, then you
 <p>To install the templates manually, simply copy (or link) them into
 this Project Templates folder.</p>
-<h2><a href="#id4" name="notes">Notes</a></h2>
+<h2><a href="#id4">Notes</a></h2>
 <li>These templates are brand new in PyObjC 1.3.1 and haven't had much
 use yet.  If you think that you have found a bug or would like them to be
 See PyObjC Mixed Application below for more information about using
 plug-ins to integrate non-Python code into your application.</li>
-<h2><a href="#id5" name="groups">Groups</a></h2>
+<h2><a href="#id5">Groups</a></h2>
 <p>The PyObjC Xcode templates use py2app to build applications,
 but they parse the <code><span>.xcode</span></code> project file to determine
 how they should be built, rather than directly in the
-<h2><a href="#id6" name="targets">Targets</a></h2>
+<h2><a href="#id6">Targets</a></h2>
 <dd><p>This target will use py2app <code><span>--alias</span></code> build mode.  Executables
 project.  The build style has no effect on Python code.</p>
-<h2><a href="#id7" name="custom-executable">Custom Executable</a></h2>
+<h2><a href="#id7">Custom Executable</a></h2>
 <p>The custom executable enables for your built application to be run from Xcode.</p>
 <p>If you rename your main script or fiddle around with your <code><span>Info.plist</span></code>,
 the path to your application may change and this will no longer work.
 <p>Custom executables are specific to a particular user in Xcode, so anything
 you do to this part of the template won't be seen by anyone else unless
 they happen to have the same short user name as you.</p>
-<h2><a href="#id8" name="pyobjc-application">PyObjC Application</a></h2>
+<h2><a href="#id8">PyObjC Application</a></h2>
 <p>This is a simple template that has a window and an application delegate.</p>
-<h2><a href="#id9" name="pyobjc-document-based-application">PyObjC Document Based Application</a></h2>
+<h2><a href="#id9">PyObjC Document Based Application</a></h2>
 <p>This is template demonstrates a Document-based application written in Python.
 It is a simple text editor (like the TinyTinyEdit example).</p>
-<h2><a href="#id10" name="pyobjc-mixed-application">PyObjC Mixed Application</a></h2>
+<h2><a href="#id10">PyObjC Mixed Application</a></h2>
 <p>This template contains both Objective-C and Python code.  The Objective-C code
 is built as a &quot;ProjectNamePlugIn.bundle&quot; plug-in in a separate target.  The plug-in
 is placed in the <code><span>Resources</span></code> directory of your application.  A wrapper script

File Doc/classes.html

View file
 <h2>Python classes and Objective-C code</h2>
 <!-- This file is formatted using the rules for reStructuredText -->
 <!-- Version 0.2 -->
-<h2><a name="introduction">Introduction</a></h2>
 <p>PyObjC is a proxy between Objective-C and Python and allows access to Python
 classes from Objective-C and vice versa.  PyObjC also allows you to subclass
 Objective-C classes from Python.</p>
-<h2><a name="accessing-python-objects-from-objective-c">Accessing Python objects from Objective-C</a></h2>
+<h2><a>Accessing Python objects from Objective-C</a></h2>
 <p>All Python objects can be accessed from Objective-C through proxy objects. 
 Whenever a Python object crosses the line from Python to Objective-C a proxy
 object is created (of class <code><span>OC_PythonObject</span></code>, a subclass of <code><span>NSProxy</span></code>).
 <p>The special cases allow for more transparent bridging between Python and
-<h2><a name="accessing-objective-c-objects-from-python">Accessing Objective-C objects from Python</a></h2>
+<h2><a>Accessing Objective-C objects from Python</a></h2>
 <p>Objective-C objects are accessed through proxy objects that forward method
 calls from Python to Objective-C.  All proxy objects are instances of 
 <code><span>objc.objc_object</span></code>, or a subclass of this class.</p>
 <p>See the section 'Method protocol' for a description of how PyObjC translates 
 between Python and Objective-C method calls.</p>
-<h2><a name="accessing-objective-c-classes-from-python">Accessing Objective-C classes from Python</a></h2>
+<h2><a>Accessing Objective-C classes from Python</a></h2>
 <p>Objective-C classes are also accessed through proxy objects, but those are
 subclasses of <code><span>objc.objc_class</span></code>.  The proxies for Objective-C classes are 
 classes in Python.</p>
 # ...
-<h2><a name="method-protocol">Method protocol</a></h2>
+<h2><a>Method protocol</a></h2>
 <p>There is a straightforward translation from Objective-C method names to
 Python method names: Concatenate all parts of the Objective-C method name
 (without any whitespace) and then replace all colons by underscores.</p>

File Doc/coding-style.html

View file
 <meta name="Author" content="Bill Bumgarner" />
 <meta name="Contact" content="pyobjc-dev@lists.sourceforge.net" />
 <meta name="copyright" content="2002 The PyObjC Project" />
 <h2>Coding style for PyObjC</h2>
 <td>2002 The PyObjC Project</td></tr>
+<table border="1" width="80%" align="center"><tbody><tr><td><i><center>Contents</center></i><br />
-<li><a href="#introduction" id="id1" name="id1">Introduction</a></li>
-<li><a href="#python-code" id="id2" name="id2">Python code</a></li>
-<li><a href="#c-code" id="id3" name="id3">C code</a></li>
-<li><a href="#documentation" id="id4" name="id4">Documentation</a><ul>
-<li><a href="#rest-in-docstrings" id="id5" name="id5">ReST in DocStrings</a></li>
+<li><a href="#introduction">Introduction</a></li>
+<li><a href="#python-code">Python code</a></li>
+<li><a href="#c-code">C code</a></li>
+<li><a href="#documentation">Documentation</a><ul>
+<li><a href="#rest-in-docstrings">ReST in DocStrings</a></li>
-<h2><a href="#id1" name="introduction">Introduction</a></h2>
+<h2><a href="#id1">Introduction</a></h2>
 <p>This document describes the coding style for PyObjC.  Please use this style for
 new code and try apply this style to existing code while working on it.</p>
 <p>The management summary: 4-space indents in Python code, 1-TAB indents in C
-<h2><a href="#id2" name="python-code">Python code</a></h2>
+<h2><a href="#id2">Python code</a></h2>
 <p>The coding style for core Python is used (see <a href="http://www.python.org/peps/pep-0008.txt">PEP 8</a>).  For consistency with
 Cocoa we use mixed-case identifiers (like <code><span>lookUpClass</span></code>).</p>
 <p>PyObjC extensions to Apple frameworks should be clearly marked as such, 
 preferably by prefixing names with <code><span>PyObjC</span></code> or <code><span>pyobjc</span></code>.  This should make
 it clear to users where they should look for documentation of an item: The
 Apple documentation or ours.</p>
-<h2><a href="#id3" name="c-code">C code</a></h2>
+<h2><a href="#id3">C code</a></h2>
 <p>The coding style for core Python is used (see <a href="http://www.python.org/peps/pep-0007.txt">PEP 7</a>).  We use <code><span>PyObjC</span></code> 
 instead of <code><span>Py</span></code> as the prefix for globally visible symbols.</p>
 <p>All (Objective-)C files in <code><span>Modules/objc/</span></code> should include <code><span>&quot;pyobjc.h&quot;</span></code> as
 their first include.  The (Objective-)C files in the wrappers for frameworks
 should include <code><span>&quot;pyobjc-api.h&quot;</span></code> and should not use other include-files in
 <code><span>Modules/objc</span></code> other than <code><span>pyobjc-api.h</span></code> and <code><span>wrapper-const-table.h</span></code>.</p>
-<h2><a href="#id4" name="documentation">Documentation</a></h2>
+<h2><a href="#id4">Documentation</a></h2>
 <p>All items exported by the objc module and all PyObjC extensions to Apple
 frameworks (the AppKit and Foundation modules) should be documented using
 <p>All documentation-- both standalone documents and docstrings-- should be
 marked up using <a href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> [ReST].</p>
-<h3><a href="#id5" name="rest-in-docstrings">ReST in DocStrings</a></h3>
+<h3><a href="#id5">ReST in DocStrings</a></h3>
 <p><a href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> can be used in doc strings.   ReST in DocStrings works
 exactly like a standalone ReST document, but the ReST is broken up slightly

File Doc/intro.html

View file
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 An introduction to PyObjC</title>
 <h2>An introduction to PyObjC</h2>
 :contact: pyobjc-dev@lists.sourceforge.net
 :URL: http://pyobjc.sourceforge.net/
 :copyright: 2003-2005 The PyObjC Project -->
+<table border="1" width="80%" align="center"><tbody><tr><td><i><center>Contents</center></i><br />
-<li><a href="#preface" id="id6" name="id6">Preface</a></li>
-<li><a href="#objective-c-for-pyobjc-users" id="id7" name="id7">Objective-C for PyObjC users</a></li>
-<li><a href="#overview-of-the-bridge" id="id8" name="id8">Overview of the bridge</a><ul>
-<li><a href="#classes" id="id9" name="id9">Classes</a></li>
-<li><a href="#messages-and-functions" id="id10" name="id10">Messages and Functions</a></li>
-<li><a href="#reference-counting" id="id11" name="id11">Reference counting</a></li>
-<li><a href="#protocols" id="id12" name="id12">Protocols</a></li>
-<li><a href="#cocoa-bindings" id="id13" name="id13">Cocoa Bindings</a></li>
-<li><a href="#categories" id="id14" name="id14">Categories</a></li>
+<li><a href="#preface">Preface</a></li>
+<li><a href="#objective-c-for-pyobjc-users">Objective-C for PyObjC users</a></li>
+<li><a href="#overview-of-the-bridge">Overview of the bridge</a><ul>
+<li><a href="#classes">Classes</a></li>
+<li><a href="#messages-and-functions">Messages and Functions</a></li>
+<li><a href="#reference-counting">Reference counting</a></li>
+<li><a href="#protocols">Protocols</a></li>
+<li><a href="#cocoa-bindings">Cocoa Bindings</a></li>
+<li><a href="#categories">Categories</a></li>
-<li><a href="#cocoa-for-python-programmers" id="id15" name="id15">Cocoa for Python programmers</a></li>
-<li><a href="#notes-on-specific-tasks" id="id16" name="id16">Notes on specific tasks</a><ul>
-<li><a href="#working-with-threads" id="id17" name="id17">Working with threads</a></li>
-<li><a href="#finalizers" id="id18" name="id18">Finalizers</a></li>
-<li><a href="#copying" id="id19" name="id19">Copying</a></li>
+<li><a href="#cocoa-for-python-programmers">Cocoa for Python programmers</a></li>
+<li><a href="#notes-on-specific-tasks">Notes on specific tasks</a><ul>
+<li><a href="#working-with-threads">Working with threads</a></li>
+<li><a href="#finalizers">Finalizers</a></li>
+<li><a href="#copying">Copying</a></li>
-<li><a href="#building-applications" id="id20" name="id20">Building applications</a><ul>
-<li><a href="#py2app-setup-py" id="id21" name="id21">&quot;py2app&quot; :  setup.py</a></li>
-<li><a href="#ide-approach-xcode" id="id22" name="id22">&quot;IDE approach&quot; : Xcode</a></li>
+<li><a href="#building-applications">Building applications</a><ul>
+<li><a href="#py2app-setup-py">&quot;py2app&quot; :  setup.py</a></li>
+<li><a href="#ide-approach-xcode">&quot;IDE approach&quot; : Xcode</a></li>
-<h2><a href="#id6" name="preface">Preface</a></h2>
+<h2><a href="#id6">Preface</a></h2>
 <p>PyObjC is a bridge between Python and Objective-C.  It allows you to write 
 Python scripts that use and extend existing Objective-C class libraries, 
 most importantly the <a href="http://developer.apple.com/referencelibrary/API_Fundamentals/Cocoa-api-date.html">Cocoa libraries</a> by <a href="http://www.apple.com/">Apple</a>.</p>
 <p>This document describes how to use Objective-C class libraries from Python
 scripts and how to interpret the documentation of those libraries from the 
 point of view of a Python programmer.</p>
-<h2><a href="#id7" name="objective-c-for-pyobjc-users">Objective-C for PyObjC users</a></h2>
+<h2><a href="#id7">Objective-C for PyObjC users</a></h2>
 <p>It is recommended that you take the time to understand a little bit about
 Objective-C before jumping into PyObjC development.  The class libraries
 that you will be using from Cocoa are not documented in Python, and their
 <li><a href="http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html">The Objective-C Programming Language</a> at <a href="http://www.apple.com/">Apple</a>.</li>
-<h2><a href="#id8" name="overview-of-the-bridge">Overview of the bridge</a></h2>
-<h3><a href="#id9" name="classes">Classes</a></h3>
+<h2><a href="#id8">Overview of the bridge</a></h2>
+<h3><a href="#id9">Classes</a></h3>
 <p>Objective-C classes are visible as (new-style) Python classes and can be 
 subclassed just like normal Python classes.  All the usual introspection
 mechanisms work as well, as do <code><span>__slots__</span></code> and descriptors.  The major 
 initializer (typically starts with <code><span>init</span></code>).  Some classes have class methods
 which perform this behind the scenes, especially classes that create cached,
 immutable, or singleton instances.</p>
-<h3><a href="#id10" name="messages-and-functions">Messages and Functions</a></h3>
+<h3><a href="#id10">Messages and Functions</a></h3>
 <p>Objective-C methods are bridged to Python methods.  Because Objective-C
 message dispatch syntax can not be translated directly to Python, a few
 simple translations must take place.  The rules for these translations are:</p>
         someMethod_ = objc.selector(someMethod_, ...)
-<h3><a href="#id11" name="reference-counting">Reference counting</a></h3>
+<h3><a href="#id11">Reference counting</a></h3>
 <p>The <a href="http://developer.apple.com/referencelibrary/API_Fundamentals/Cocoa-api-date.html">Cocoa libraries</a>, and most (if not all) other class libraries for 
 Objective-C use explicit reference counting to manage memory.  The methods
 <code><span>retain</span></code>, <code><span>release</span></code> and <code><span>autorelease</span></code> are used to manage these 
 subclasses of <code><span>NSObject</span></code> to represent the nodes in the outline view.</p>
 <p>Another gotcha is that <code><span>obj.setDelegate_()</span></code> often does <i>not</i> retain the
 delegate, so a reference should be maintained elsewhere.</p>
-<h3><a href="#id12" name="protocols">Protocols</a></h3>
+<h3><a href="#id12">Protocols</a></h3>
 <p>Cocoa defines a number of formal and informal protocols that specify methods
 that should be implemented by a class if it is to be used in a specific role,
 such as the data source for an <code><span>NSTableView</span></code>.</p>
 objects to add the right method signatures to methods, and to warn about
 classes that partially implement a protocol.</p>
 <p>See <a href="protocols.html">PyObjC protocol support</a> for more information.</p>
-<h3><a href="#id13" name="cocoa-bindings">Cocoa Bindings</a></h3>
+<h3><a href="#id13">Cocoa Bindings</a></h3>
 <p>In Mac OS X 10.3 Apple introduced <a href="http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/">Cocoa Bindings</a>, a method to make it easier
 to create and use <i>Controller</i> objects using <a href="http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueObserving/">Key-Value Observing</a> and
 <a href="http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/">Key-Value Coding</a>.  In order to create accessors compatible with this, you
 must use <code><span>objc.accessor</span></code> to create an appropriate selector descriptor.</p>
-<h3><a href="#id14" name="categories">Categories</a></h3>
+<h3><a href="#id14">Categories</a></h3>
 <p>Objective-C has a mechanism for modularize a class definition, it is possible
 to add methods to an existing class in a separate compilation unit and even
 a separate library.  This mechanism is named categories and is used to enhance
 <p>To make it clear that <code><span>objc.Category</span></code> performs a special task the name in
 the class definition must be the same as the <code><span>__name__</span></code> of the argument
 to <code><span>objc.Category</span></code>.</p>
-<h2><a href="#id15" name="cocoa-for-python-programmers">Cocoa for Python programmers</a></h2>
+<h2><a href="#id15">Cocoa for Python programmers</a></h2>
 <p>Cocoa frameworks are mapped onto Python packages with the same name; that is
 the classes, constants and functions from the AppKit framework are available
 after you import <code><span>AppKit</span></code> in your Python script.</p>
 <li><a href="http://www.stepwise.com/">stepwise.com</a></li>
 <li>Your local bookstore or library</li>
-<h2><a href="#id16" name="notes-on-specific-tasks">Notes on specific tasks</a></h2>
-<h3><a href="#id17" name="working-with-threads">Working with threads</a></h3>
+<h2><a href="#id16">Notes on specific tasks</a></h2>
+<h3><a href="#id17">Working with threads</a></h3>
 <p>When you create a thread and want to use PyObjC from that thread you will
 have to create an <code><span>NSAutoreleasePool</span></code> in that thread and clean it up when
 you're done.  The easiest way to that is to create an instance of that class
 bound to a local variable.  If the thread is long-lived you may want to arrange
 for recycling the pool once in a while.</p>
-<h3><a href="#id18" name="finalizers">Finalizers</a></h3>
+<h3><a href="#id18">Finalizers</a></h3>
 <p>In Python you can use the method <code><span>__del__</span></code> to clean up resources when your
 object is garbage collected.  In Objective-C/Cocoa this is done with a method 
 named <code><span>dealloc</span></code>.</p>
 <p>In Python subclasses of Objective-C classes you can use either convention.  You
 should pick one convention for your own code, the order in which <code><span>__del__</span></code>
 and <code><span>dealloc</span></code> methods are called is undefined.</p>
-<h3><a href="#id19" name="copying">Copying</a></h3>
+<h3><a href="#id19">Copying</a></h3>
 <p>It is possible to implement the <code><span>NSCopying</span></code> protocol in your classes.  Some
 care must be taken when you inherit from a class that already implements 
 that protocol.</p>
 <p>NOTE2: You shouldn't assign to <code><span>SomeClass.copyWithZone_</span></code> unless that class
 already implements <code><span>copyWithZone:</span></code>.  If you do you may end up with seemingly
 random memory coruption.</p>
-<h2><a href="#id20" name="building-applications">Building applications</a></h2>
+<h2><a href="#id20">Building applications</a></h2>
 <p>There are two different recommended ways to build applications with PyObjC.</p>
-<h3><a href="#id21" name="py2app-setup-py">&quot;py2app&quot; :  setup.py</a></h3>
+<h3><a href="#id21">&quot;py2app&quot; :  setup.py</a></h3>
 <p>The PyObjC installer includes a copy of the <code><span>py2app</span></code> package.  This package
 offers a way to build distutils scripts for building (standalone)
 applications and plugin bundles.</p>
 python setup.py py2app --help
-<h3><a href="#id22" name="ide-approach-xcode">&quot;IDE approach&quot; : Xcode</a></h3>
+<h3><a href="#id22">&quot;IDE approach&quot; : Xcode</a></h3>
 <p>PyObjC includes a number of Xcode templates that can be used to 
 develop applications, using the same underlying functionality that
 is in py2app.  These templates are used like any other Xcode template,

File NEWS.html

View file
 <h2>PyObjC NEWS</h2>
 <p>An overview of the relevant changes in new, and older, releases.</p>
-<h2><a name="version-1-3-5-2005-05">Version 1.3.5 (2005-05-??)</a></h2>
+<h2><a>Version 1.3.5 (2005-05-??)</a></h2>
 <li>Key-Value Coding of Python objects should act like Objective-C now.
 Previously, its capitalization method didn't match Objective-C's, it
 <code><span>array.array</span></code> (but not <code><span>str</span></code> or <code><span>unicode</span></code>) are now bridged as
 <code><span>NSData</span></code> subclasses.</li>
-<h2><a name="version-1-3-2005-03-31">Version 1.3 (2005-03-31)</a></h2>
+<h2><a>Version 1.3 (2005-03-31)</a></h2>
 <li>New <code><span>objc.pyobjc_id</span></code> function that returns a the id of the underlying
 NSObject as an integer.  (Python wrapper objects are often made on the
 function is also exposed in the C API (and has been for a while).</p>
-<h2><a name="version-1-2-2004-12-29">Version 1.2 (2004-12-29)</a></h2>
+<h2><a>Version 1.2 (2004-12-29)</a></h2>
 <li><code><span>PyObjCTools.AppHelper.stopEventLoop</span></code> will attempt to stop the current
 <code><span>NSRunLoop</span></code> (if started by <code><span>runConsoleEventLoop</span></code>) or terminate the
 packages as <code><span>objc._objc</span></code>, <code><span>AppKit._AppKit</span></code>, etc.  They should never be
 used directly, so this should not break user code.</li>
-<h2><a name="version-1-1-2004-05-30">Version 1.1 (2004-05-30)</a></h2>
+<h2><a>Version 1.1 (2004-05-30)</a></h2>
 <li>KVO now actually works from Python without using nasty hacks.</li>
 <li>Added Xcode template for document-based applications</li>
-<h2><a name="version-1-1b2-2004-04-11">Version 1.1b2 (2004-04-11)</a></h2>
+<h2><a>Version 1.1b2 (2004-04-11)</a></h2>
 <li>More fine-grained multi-threading support</li>
 <li>Xcode templates use a smarter embedded main program</li>
 expression in Objective-C.</li>
 <li>Add several new examples</li>
-<h2><a name="version-1-1b1-2004-02-20">Version 1.1b1 (2004-02-20)</a></h2>
+<h2><a>Version 1.1b1 (2004-02-20)</a></h2>
 <li>Fixes some regressions in 1.1 w.r.t. 1.0</li>
 <li>Add Xcode templates for python files<p>You can now select a new python file in the 'add file...' dialog in Xcode</p>
 accessor method.</p>
-<h2><a name="version-1-1a0-2004-02-02">Version 1.1a0 (2004-02-02)</a></h2>
+<h2><a>Version 1.1a0 (2004-02-02)</a></h2>
 <li>Objective-C structs can now be wrapped using struct-like types. This has
 been used to implement wrapper types for NSPoint, NSSize, NSRange and NSRect
-<h2><a name="version-1-0-2003-09-21">Version 1.0 (2003-09-21)</a></h2>
+<h2><a>Version 1.0 (2003-09-21)</a></h2>
 <li>This version includes a new version of libffi that properly deals with
 complex types on MacOS X.</li>
-<h2><a name="version-1-0rc3-2003-09-14">Version 1.0rc3 (2003-09-14)</a></h2>
+<h2><a>Version 1.0rc3 (2003-09-14)</a></h2>
 <li>1.0rc2 didn't include the nibclassbuilder script</li>
 <li>Fix bug in NSRectFillList</li>
-<h2><a name="version-1-0rc2-2003-09-10">Version 1.0rc2 (2003-09-10)</a></h2>
+<h2><a>Version 1.0rc2 (2003-09-10)</a></h2>
 <li>Fix a number of bugs found in 1.0rc1.</li>
-<h2><a name="version-1-0rc1-2003-08-10">Version 1.0rc1 (2003-08-10)</a></h2>
+<h2><a>Version 1.0rc1 (2003-08-10)</a></h2>
 <li>Better support for the NSKeyValueCoding protocol.  The module 
 <code><span>PyObjCTools.KeyValueCoding</span></code> provides a python interface that makes it
 <li>The interface of Foundation.NSFillRects changed, it now has an interface
 that is consistent with the rest of the bridge.</li>
-<h2><a name="version-1-0b1-2003-07-05">Version 1.0b1 (2003-07-05)</a></h2>
+<h2><a>Version 1.0b1 (2003-07-05)</a></h2>
 <li>More tutorials<p>Two new tutorials were added: 'Adding Python code to an existing ObjC 
 application' and 'Understanding existing PyObjC examples'. The former
 <li>The generator scripts are automaticly called when building PyObjC. This
 should make it easier to support multiple versions of MacOS X.</li>
-<h2><a name="version-0-9-may-02-2003">Version 0.9 (May-02-2003)</a></h2>
+<h2><a>Version 0.9 (May-02-2003)</a></h2>
 <li>This version includes numerous bugfixes and improvements.</li>
 <li>The module AppKit.NibClassBuilder has been moved to the package
 makes it easily possible to use NSString values with Python APIs, while at 
 the same time allowing access to the full power of NSString.</li>
-<h2><a name="version-0-8-dec-10-2002">Version 0.8 (Dec-10-2002)</a></h2>
+<h2><a>Version 0.8 (Dec-10-2002)</a></h2>
 <li>GNUStep support has been removed for lack of support.  Volunteers
 <li>Support for Project Builder based Cocoa-Python projects.</li>
 <li>Unit tests.</li>
-<h2><a name="version-2002-01-30-january-30-2002">Version 2002-01-30 (January 30, 2002)</a></h2>
+<h2><a>Version 2002-01-30 (January 30, 2002)</a></h2>
 <li>Version bumped to 0.6.1 ( __version__ is now a PyString )</li>
 <li>Will now build for Python 2.2</li>
 without check, it crashes on sends to abstract classes like NSProxy.</li>
 <li>There are still problems with Delegates and Notifications.</li>
-<h2><a name="version-2001-03-17-march-17-2001">Version 2001-03-17 (March 17, 2001)</a></h2>
+<h2><a>Version 2001-03-17 (March 17, 2001)</a></h2>
 <li>moved to using distutils setup.py (requires small patch to distutils
 that has been submitted against python 2.1b1)</li>
-<h2><a name="version-2000-11-14-november-14-2000">Version 2000-11-14 (November 14, 2000)</a></h2>
+<h2><a>Version 2000-11-14 (November 14, 2000)</a></h2>
 <li>GNU_RUNTIME is likely completely broken</li>
 <li>Compiles on Mac OS X Server (python 2.0)</li>
 <li>Some pre-OSX stuff removed;  references to old APIs, etc... (but
 nowhere near clean)</li>
-<h2><a name="version-0-55-18-august-1998">Version 0.55, 18 August 1998</a></h2>
+<h2><a>Version 0.55, 18 August 1998</a></h2>
 <li>Here again, supporting GNU_RUNTIME and GNUstep Base! On my new Linux
 box I can finally test the module against them: I installed the
-<h2><a name="version-0-54-24-march-1998">Version 0.54, 24 March 1998</a></h2>
+<h2><a>Version 0.54, 24 March 1998</a></h2>
 <li>OC_Pasteboard.[hm], OC_Stream.[mh] and ObjCStreams.m are definitively gone.</li>
 <li>OC_PythonObject derives from NSProxy.</li>
-<h2><a name="version-0-53-4-january-1998">Version 0.53, 4 January 1998</a></h2>
+<h2><a>Version 0.53, 4 January 1998</a></h2>
 <li>Tons of changes, retargeting the core functionality around the
 OpenSTEP API. This release basically matches the previous one
 if they are needed anymore.</li>
 <li>Updated LittleButtonedWindow demo.</li>
-<h2><a name="version-0-47-29-october-1996">Version 0.47, 29 October 1996</a></h2>
+<h2><a>Version 0.47, 29 October 1996</a></h2>
 <li>Misc/Makefile.pre.in automatically sets TARGET to <code><span>pyobjc</span></code>.</li>
 <li>ObjC.m splitted to ObjCObject.m ObjCMethod.m ObjCPointer.m
 <li>OC_Streams are mapped to ObjCStreams by pythonify_c_value and its
-<h2><a name="version-0-46-18-october-1996">Version 0.46, 18 October 1996</a></h2>
+<h2><a>Version 0.46, 18 October 1996</a></h2>
 <li>OC_Stream is now a subclass of NSData under Foundation.</li>
 <li>New Objective-C class: OC_Pasteboard. Use it instead of Pasteboard/
 <li>OC_Python.[hm] aren't in the package anymore.</li>
 <li>Setup.in directives changed again, due to OC_Python.m dropping.</li>
-<h2><a name="version-0-45-14-october-1996">Version 0.45, 14 October 1996</a></h2>
+<h2><a>Version 0.45, 14 October 1996</a></h2>
 <li>Double syntax: to make it easier for us to test and choose the
 better candidate, the only one that will be present in the final 1.0
 release. Keeping both would result in a speed penality.</li>
 <li>Revisited streams, in particular GNUstep support.</li>
-<h2><a name="version-0-44-9-october-1996">Version 0.44, 9 October 1996</a></h2>
+<h2><a>Version 0.44, 9 October 1996</a></h2>
 <li>Integers are now accepted too where floats or doubles are expected.</li>
 <li>New method: ObjC.make_pointer (1) returns an ObjCPointer containing
 <code><span>((void</span> <span>*)</span> <span>1)</span></code>.</li>
-<h2><a name="version-0-43-7-october-1996">Version 0.43, 7 October 1996</a></h2>
+<h2><a>Version 0.43, 7 October 1996</a></h2>
 <li>Completed ObjCStream implementation. There is now a new module, ObjCStreams
 which is automatically loaded by ObjC. You can access it as ObjC.streams.</li>
 libObjC.tex describing the main module, libObjCStreams.tex explains the
 stream facilities.</li>
-<h2><a name="version-0-42-4-october-1996">Version 0.42, 4 October 1996</a></h2>
+<h2><a>Version 0.42, 4 October 1996</a></h2>
 <li>You can pass initialization arguments when using the <code><span>Class()</span></code> syntax. You
 select the right initializer selector with the <code><span>init</span></code> keyword parameter.</li>
 <li>First cut on ObjCStream objects. Thanx to Bill Bumgarner for motivations.</li>
 <li>New demo ShellText, to test above points.</li>
-<h2><a name="version-0-41-2-october-1996">Version 0.41, 2 October 1996</a></h2>
+<h2><a>Version 0.41, 2 October 1996</a></h2>
 <li>Revised error messages: for arguments type mismatch they show the ObjC type
 <li>Setup.in directives changed. See the new file Modules/Setup.PyObjC.in</li>
 <li>Distribuited as a standalone package. Special thanks to Bill Bumgarner.</li>
-<h2><a name="version-0-4-27-september-1996">Version 0.4, 27 September 1996</a></h2>
+<h2><a>Version 0.4, 27 September 1996</a></h2>
 <li>Now handles methods returning doubles or floats.</li>
 <li>ObjCRuntime responds to .sel_is_mapped().</li>
-<h2><a name="version-0-31-26-september-1996">Version 0.31, 26 September 1996</a></h2>
+<h2><a>Version 0.31, 26 September 1996</a></h2>
 <li>It's now possible to use a different strategy to map ObjC method names to
 Python ones. Sooner or later we should decide the one to go, and drop the
 <li>ObjC.runtime.__dict__ added.</li>
 <li>ObjC.runtime.kind added.</li>
-<h2><a name="version-0-3-20-september-1996">Version 0.3, 20 September 1996</a></h2>
+<h2><a>Version 0.3, 20 September 1996</a></h2>
 <li>No user visible changes, just a little effort towards GNU_RUNTIME support.</li>
-<h2><a name="version-0-2-16-september-1996">Version 0.2, 16 September 1996</a></h2>
+<h2><a>Version 0.2, 16 September 1996</a></h2>
 <li>Accepts a struct.pack() string for pointer arguments, but...</li>
 <li>... New methods on ObjCMethod: .pack_argument and .unpack_argument:
-<h2><a name="version-0-1-13-september-1996">Version 0.1, 13 September 1996</a></h2>
+<h2><a>Version 0.1, 13 September 1996</a></h2>
 <li>Correctly handle pointer arguments.</li>
 <li>New syntax to get a class: ObjC.runtime.NameOfClass</li>

File NEWS.txt

View file
   - ``CoreData``
   - ``DiscRecording``
   - ``DiscRecordingUI``
+  - ``OSAKit``
   - ``Quartz``
   - ``QTKit``
   - ``SyncServices``
 - Add a CoreData example: a python version of the OutlineEditor example
   from Apple.
-  TODO: compile the .xcdatamodel file.
 - If the selector name ends with ':error:' and the last argument is a pointer
   to an object, the argument is now assumed to be an output argument.

File Scripts/CodeGenerators/cocoa_generator.py

View file
     QUARTZ_HDRS=pathjoin(FRAMEWORKS, "Quartz.framework", "Headers")
     QUARTZ2_HDRS=pathjoin(FRAMEWORKS, "Quartz.framework", "Frameworks", "QuartzComposer.framework", "Headers")
     QUARTZ3_HDRS=pathjoin(FRAMEWORKS, "Quartz.framework", "Frameworks", "PDFKit.framework", "Headers")
+    OSAKIT_HDRS=pathjoin(FRAMEWORKS, "OSAKit.framework", "Headers")
     # This is probably incorrect, and was added to help a future
+if OSAKIT_HDRS is not None:
+    enum_generator.generate(
+            OSAKIT_HDRS,
+            'build/codegen/_OSAKit_Enum.inc')
+    strconst_generator.generate(
+            OSAKIT_HDRS,
+            'build/codegen/_OSAKit_Str.inc')
 if QUARTZ_HDRS is not None:

File Scripts/find-raw-pointers.py

View file
 except ImportError:
+    import CoreData
+except ImportError:
+    pass

File Scripts/gen_all_protocols.py

View file
 # Optional frameworks
 for framework in [
         "WebKit", "ExceptionHandling", "SecurityInterface", "AppleScriptKit",
-        "AppKitScripting", "Automator", "CoreData", "XgridFoundation",
-        "SyncServices", "DiscRecording", "DiscRecordingUI", 'QTKit',
+        "Automator", "CoreData", "XgridFoundation",
+        "SyncServices", "DiscRecording", "DiscRecordingUI", 'QTKit', "OSAKit",
     path = "/System/Library/Frameworks/%s.framework" % framework
     protfile = file(os.path.join(libdir, framework, "protocols.py"), "w")

File setup.py

View file
 XgridFoundationDepends = dict(depends=INCFILES)
 QTKitDepends = dict(depends=INCFILES)
 QuartzDepends = dict(depends=INCFILES)
+OSAKitDepends = dict(depends=INCFILES)
 FoundationPackages, FoundationExtensions = \
         IfFrameWork('Foundation.framework', [ 'Foundation' ], [
         ], headername="Quartz.h")
+OSAKitPackages, OSAKitExtensions = \
+        IfFrameWork('OSAKit.framework', [ 'OSAKit' ], [
+            Extension('OSAKit._OSAKit',
+                      [ 'Modules/OSAKit/_OSAKit.m' ],
+                      extra_compile_args=[
+                        '-IModules/objc',
+                      ] + CFLAGS,
+                      extra_link_args=frameworks(
+                        'OSAKit',
+                        'Foundation'
+                      ),
+                      **OSAKitDepends
+                      ),
+        ], headername="OSAKit.h")
 AppleScriptKitPackages, AppleScriptKitExtensions = \
         IfFrameWork('AppleScriptKit.framework', [ 'AppleScriptKit' ], [
     XgridFoundationPackages +
     QTKitPackages +
     QuartzPackages +
+    OSAKitPackages +
        + AutomatorExtensions
        + QTKitExtensions
        + QuartzExtensions
+       + OSAKitExtensions
        + CoreDataExtensions
        + DiscRecordingExtensions
        + DiscRecordingUIExtensions