Commits

Bob Ippolito committed 2c4c50e

Bump version to 1.3.9
Remove references to Project Builder

Comments (0)

Files changed (12)

Doc/ProjectBuilder-SyntaxHighlighting.html

-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-<title>
-Project Builder Python Support</title>
-<meta name="Author" content="Bill Bumgarner" />
-<meta name="Contact" content="&lt;bbum@codefab.com&gt;" />
-<meta name="version" content="0.1 (unsupported)" />
-<meta name="date" content="12/16/2002" />
-<title>
-Contents</title>
-</head>
-<body>
-<h2>Project Builder Python Support</h2>
-<table>
-<tbody valign="top">
-<tr><th >Author:</th>
-<td>Bill Bumgarner</td></tr>
-<tr><th >Contact:</th>
-<td>&lt;<a href="mailto:bbum@codefab.com">bbum@codefab.com</a>&gt;</td></tr>
-<tr><th >Version:</th>
-<td>0.1 (unsupported)</td></tr>
-<tr><th >Date:</th>
-<td>12/16/2002</td></tr>
-</tbody>
-</table>
-<table width="90%" border="1" align="center">
-<tbody><tr><td><table width="100%"><tbody><tr>
-<td bgcolor="#ffff33" width="15%">
-Warning</td><td><p>Project Builder support is not maintained in PyObjC, is likely
-out of date, and is not guaranteed to work at all.
-None of this is documented or supported by <strong>Apple</strong>.  Don't ask <strong>Apple</strong> for
-support and don't blame me if something breaks.  A lot could break as
-<strong>Project Builder</strong> stores a tremendous amount of highly dynamic information in
-both the user defaults and within project files.</p>
-</td></tr></tbody></table></td></tr></tbody></table><h2>Contents</h2>
-<ul>
-<li><a href="#installation" id="id1" name="id1">Installation</a></li>
-<li><a href="#documentation" id="id2" name="id2">Documentation</a></li>
-<li><a href="#to-do" id="id3" name="id3">To Do</a></li>
-</ul>
-<p>Triple-quoted strings are not always treated correctly by Project Builder. This
-seems to be a Project Builder bug.</p>
-<h2><a href="#id1" name="installation">Installation</a></h2>
-<p>Create the directory 'Specifications' within
-<i>~/Developer/ProjectBuilder Extras/</i> or <i>/Developer/ProjectBuilder
-Extras/</i>:</p>
-<pre>
-mkdir -p ~/Developer/ProjectBuilder\ Extras/Specifications/
-</pre>
-<p>Copy the specification files into that directory:</p>
-<pre>
-cp Python.pb*spec ~/Developer/ProjectBuilder\ Extras/Specifications/
-</pre>
-<p>The binary installer will install the specifications for you.</p>
-<h2><a href="#id2" name="documentation">Documentation</a></h2>
-<p>The version of Project Builder that ships with the December Developer Tools
-modularizes the support for file types and syntax based colorizing of
-source files.  The base mechanisms and definitions are found in:</p>
-<p><a href="file:///System/Library/PrivateFrameworks/PBXCore.framework/Resources/">file:///System/Library/PrivateFrameworks/PBXCore.framework/Resources/</a></p>
-<p>Not surprisingly, Apple has provided a mechanism for augmenting and
-overriding the configuration information found within the PBXCore
-framework.  By creating a 'Specifications' directory within any of the
-<i>ProjectBuilder Extras</i> directories (<i>/Developer/ProjectBuilder Extras</i>
-and <i>~/Developer/ProjectBuilder Extras</i> being the two most common).</p>
-<p>All of the various specification files are simply property lists.  The file
-names do not appear to be significant beyond the extension.  That is,
-<i>Python.pblangspec</i> could have been called <i>Foo.pblangspec</i> and it would still
-work as expected.</p>
-<p>The contents of the two files were determined largely by looking through the
-files found in the PBXCore framework.  The list of keywords for python was
-generated by python itself:</p>
-<pre>
-In [1]: import keyword            
-In [2]: keyword.kwlist
-Out[2]: 
-['and',
- 'assert',
- 'break',
- 'class',
- 'continue',
- 'def',
- 'del',
- 'elif',
- 'else',
- 'except',
- 'exec',
- 'finally',
- 'for',
- 'from',
- 'global',
- 'if',
- 'import',
- 'in',
- 'is',
- 'lambda',
- 'not',
- 'or',
- 'pass',
- 'print',
- 'raise',
- 'return',
- 'try',
- 'while',
- 'yield']
-</pre>
-<h2><a href="#id3" name="to-do">To Do</a></h2>
-<ul>
-<li>NOTE: PyObjC's Project Builder support is unmaintained.  It is unlikely that
-any of these items will ever be completed.</li>
-<li>There are a number of other specification files found within the PBXCore.  Of
-particular relevance to Python would be the Compiler Specifications.  It
-would be extremely handy to be able to check syntax and compile Python code
-from within PBX directly.   This appears to be a matter of both specifying
-how the compiler should be invoked and providing a set of regular
-expressions for parsing the output.</li>
-<li>Instead of invoking Python directly, a compiler specification that used
-<a href="http://pychecker.sourceforge.net/">PyChecker</a> would provide both syntactical checker and higher level script
-integrity tests.</li>
-<li>Expanding the language definition to include a list of alternative keywords
-would provide for highlighting many common Python constructs and modules, as
-well.</li>
-<li>Looking at the internals to PBXCore, support for context-clicking (i.e. cmd-
-and opt- double-clicking on keywords found in Python source) could be
-supported if one were to build a custom Python Parser/Lexer as a PBX
-plugin.</li>
-<li>Support for Jython.  On the syntax front, this would be a matter of
-duplicating a number of the keyword bits from the Java configuration.  On
-the compiler front, support would focus on feeding through to the mechanism
-that turns Python source into .class files.   All of this assumes that
-Python and Jython source can (and should?) be differentiated.</li>
-</ul>
-</body>
-</html>

Doc/ProjectBuilder-SyntaxHighlighting.txt

-==============================
-Project Builder Python Support
-==============================
-:Author: Bill Bumgarner
-:Contact: <bbum@codefab.com>
-:Version: 0.1 (unsupported)
-:Date: 12/16/2002
-
-.. WARNING::
-   Project Builder support is not maintained in PyObjC, is likely
-   out of date, and is not guaranteed to work at all.
-   None of this is documented or supported by **Apple**.  Don't ask **Apple** for
-   support and don't blame me if something breaks.  A lot could break as
-   **Project Builder** stores a tremendous amount of highly dynamic information in
-   both the user defaults and within project files.
-
-.. Contents::
-
-Triple-quoted strings are not always treated correctly by Project Builder. This
-seems to be a Project Builder bug.
-
-Installation
-------------
-
-Create the directory 'Specifications' within
-*~/Developer/ProjectBuilder Extras/* or */Developer/ProjectBuilder
-Extras/*::
-
-    mkdir -p ~/Developer/ProjectBuilder\ Extras/Specifications/
-
-Copy the specification files into that directory::
-
-    cp Python.pb*spec ~/Developer/ProjectBuilder\ Extras/Specifications/
-
-The binary installer will install the specifications for you.
-
-Documentation
--------------
-
-The version of Project Builder that ships with the December Developer Tools
-modularizes the support for file types and syntax based colorizing of
-source files.  The base mechanisms and definitions are found in:
-
-file:///System/Library/PrivateFrameworks/PBXCore.framework/Resources/
-
-Not surprisingly, Apple has provided a mechanism for augmenting and
-overriding the configuration information found within the PBXCore
-framework.  By creating a 'Specifications' directory within any of the
-*ProjectBuilder Extras* directories (*/Developer/ProjectBuilder Extras*
-and *~/Developer/ProjectBuilder Extras* being the two most common).
-
-All of the various specification files are simply property lists.  The file
-names do not appear to be significant beyond the extension.  That is,
-*Python.pblangspec* could have been called *Foo.pblangspec* and it would still
-work as expected.
-
-The contents of the two files were determined largely by looking through the
-files found in the PBXCore framework.  The list of keywords for python was
-generated by python itself::
-
-      In [1]: import keyword            
-      In [2]: keyword.kwlist
-      Out[2]: 
-      ['and',
-       'assert',
-       'break',
-       'class',
-       'continue',
-       'def',
-       'del',
-       'elif',
-       'else',
-       'except',
-       'exec',
-       'finally',
-       'for',
-       'from',
-       'global',
-       'if',
-       'import',
-       'in',
-       'is',
-       'lambda',
-       'not',
-       'or',
-       'pass',
-       'print',
-       'raise',
-       'return',
-       'try',
-       'while',
-       'yield']
-
-To Do
------
-
-- NOTE: PyObjC's Project Builder support is unmaintained.  It is unlikely that
-  any of these items will ever be completed.
-
-- There are a number of other specification files found within the PBXCore.  Of
-  particular relevance to Python would be the Compiler Specifications.  It
-  would be extremely handy to be able to check syntax and compile Python code
-  from within PBX directly.   This appears to be a matter of both specifying
-  how the compiler should be invoked and providing a set of regular
-  expressions for parsing the output.
-
-- Instead of invoking Python directly, a compiler specification that used
-  PyChecker_ would provide both syntactical checker and higher level script
-  integrity tests. 
-
-- Expanding the language definition to include a list of alternative keywords
-  would provide for highlighting many common Python constructs and modules, as
-  well.
-
-- Looking at the internals to PBXCore, support for context-clicking (i.e. cmd-
-  and opt- double-clicking on keywords found in Python source) could be
-  supported if one were to build a custom Python Parser/Lexer as a PBX
-  plugin.
-
-- Support for Jython.  On the syntax front, this would be a matter of
-  duplicating a number of the keyword bits from the Java configuration.  On
-  the compiler front, support would focus on feeding through to the mechanism
-  that turns Python source into .class files.   All of this assumes that
-  Python and Jython source can (and should?) be differentiated.
-
-.. _PyChecker: http://pychecker.sourceforge.net/

Doc/ProjectBuilder-Templates.html

-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-<title>
-Python Project Templates</title>
-<meta name="Author" content="Bill Bumgarner" />
-<meta name="Contact" content="bbum@codefab.com" />
-<title>
-Contents</title>
-</head>
-<body>
-<h2>Python Project Templates</h2>
-<table>
-<tbody valign="top">
-<tr><th >Author:</th>
-<td>Bill Bumgarner</td></tr>
-<tr><th >Contact:</th>
-<td><a href="mailto:bbum@codefab.com">bbum@codefab.com</a></td></tr>
-</tbody>
-</table>
-<p>To use the project templates, simply copy (or link) them into the Project
-Templates directory used by Project Builder.  The project templates are also
-included in the PyObjC installer package.</p>
-<h2>Contents</h2>
-<ul>
-<li><a href="#notes" id="id2" name="id2">Notes</a></li>
-<li><a href="#cocoa-python-templates" id="id3" name="id3">Cocoa-Python Templates</a></li>
-<li><a href="#cocoa-python-application" id="id4" name="id4">Cocoa-Python Application</a></li>
-<li><a href="#cocoa-python-objc-application" id="id5" name="id5">Cocoa-Python-ObjC Application</a></li>
-<li><a href="#cocoa-python-document-based-application" id="id6" name="id6">Cocoa-Python Document-based Application</a></li>
-<li><a href="#cocoa-python-objc-document-based-application" id="id7" name="id7">Cocoa-Python-ObjC Document-based Application</a></li>
-</ul>
-<h2><a href="#id2" name="notes">Notes</a></h2>
-<ul>
-<li>PyObjC's Project Builder support is unmaintained and its use for new projects
-is not recommended.</li>
-<li>In all cases that involve loading frameworks or bundles, all of the classes
-in that framework or bundle can be made available by using the
-<code><span>loadBundle()</span></code> function in the <code><span>objc</span></code> module:<pre>
-objc.loadBundle(&quot;MyFramework&quot;, globals(), bundle_path=&quot;/path/to/MyFramework.framework&quot;)
-</pre>
-<p>This has the effect of importing all of the classes in the bundle or
-framework into the current python scope's globals.  For all intents and
-purposes, it is similar to:</p>
-<pre>
-from Foundation import *
-</pre>
-</li>
-<li>There is risk that the PyObjC modules compiled for one version of python
-will not work with another.  Where this may be a problem is if the a
-standalone application is packaged with the PyObjC modules compiled
-against, say, the Fink or Framework builds of Python, but is then executed
-using the Apple supplied python binary.</li>
-</ul>
-<blockquote>
-<ul>
-<li>The <i>Project Templates</i> directory includes a <strong>clean.py</strong> script that
-removes noise files from the project templates.   When working on project
-templates, it is recommended that this script be invoked before creating a
-test project from one of the templates.   For example, the presence of
-user specific project builder settings will cause any projects created
-from a template to be incorrect.</li>
-</ul>
-</blockquote>
-<h2><a href="#id3" name="cocoa-python-templates">Cocoa-Python Templates</a></h2>
-<p>The Cocoa-Python templates all create various different kinds of Cocoa
-application projects.   Some of the resulting projects are incompatible with
-Apple's build of Python[#].  Be sure and pick the correct project type for your
-needs.</p>
-<h2><a href="#id4" name="cocoa-python-application">Cocoa-Python Application</a></h2>
-<p>A project created from this template is designed to implement standalone,
-pure-Python, applications that are compatible with Apple's build of Python as
-well as all other builds of python that support PyObjC.</p>
-<p>When building the 'install' target, the resulting application wrapper will
-included the PyObjC module and can be launched on any stock OS X 10.2 system
-without requiring PyObjC to be preinstalled.</p>
-<h2><a href="#id5" name="cocoa-python-objc-application">Cocoa-Python-ObjC Application</a></h2>
-<p>A project created from this template includes an embedded framework project
-into which all compiled code can be placed.  Upon launch, the application
-automatically dynamically loads the embedded framework containing the
-compiled code.</p>
-<p>Each Framework's Resources directory is automatically added to sys.path.</p>
-<!-- Cocoa-Python Application (Embedded Interpreter)
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-<!-- This project template uses an embedded Python interpreter.  As such,
-Objective-C classes can be freely mixed into the project along with Python
-classes.   However, because it uses an embedded interpreter, this project
-must be built and run after some version of Python is installed that can
-support an embedded interpreter.  Alternatively, an application based on this
-template must include a build of Python within its app wrapper. -->
-<!-- This type of project is not compatible with Apple's build of Python. -->
-<h2><a href="#id6" name="cocoa-python-document-based-application">Cocoa-Python Document-based Application</a></h2>
-<p>This template works like the <a href="#cocoa-python-application">Cocoa-Python Application</a> template in that it
-is compatible with the Apple build of Python.   It creates an application
-that uses Cocoa's Multiple Document Architecture in the same fashion as the
-default Cocoa Document-based Application supplied with Project Builder.</p>
-<h2><a href="#id7" name="cocoa-python-objc-document-based-application">Cocoa-Python-ObjC Document-based Application</a></h2>
-<p>A project created from this template includes an embedded framework project
-into which all compiled code can be placed.  Upon launch, the application
-automatically dynamically loads the embedded framework containing the
-compiled code. It is based on the <a href="#cocoa-python-document-based-application">Cocoa-Python Document-based Application</a>
-template.  It creates an application that uses Cocoa's Multiple Document 
-Architecture in the same fashion as the default Cocoa Document-based 
-Application supplied with Project Builder.</p>
-<p>Each Framework's Resources directory is automatically added to sys.path.</p>
-<!-- Cocoa-Python Document-based Application (Embedded Interpreter)
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-<!-- This template works like the `Cocoa-Python Application (Embedded
-Interpreter)`_ template in that it is incompatible with the Apple build of
-Python.   It creates an application that uses Cocoa's Multiple Document
-Architecture in the same fashion as the default Cocoa Document-based
-Application supplied with Project Builder. -->
-<hr /><table id="id1">
-<tbody valign="top">
-<tr><td><b>[<a name="id1">1</a>]</b></td><td><font size=-1><i>Apple's build of python lacks a shared or static library to which an
-application can be linked.  As such, it is impossible to embed the
-Python interpreter into an application.  Because of this, it is
-impossible to directly link compiled objective-c directly into an
-application project.  Hence, the &quot;Apple Python compatible&quot; projects are
-labeled as 100% pure Python.  Since bundles and frameworks can be
-loaded into such applications, it is still possible to use compiled
-classes.</i></font><br />
-</td></tr>
-</tbody>
-</table>
-</body>
-</html>
 <li><a href="#less-important-items" id="id6" name="id6">Less important items</a><ul>
 <li><a href="#refactor-some-parts-of-the-bridge" id="id7" name="id7">Refactor some parts of the bridge</a></li>
 <li><a href="#support-for-gnustep" id="id8" name="id8">Support for GNUstep</a></li>
-<li><a href="#project-templates" id="id9" name="id9">Project templates</a></li>
-<li><a href="#complete-cocoa-wrapping" id="id10" name="id10">Complete Cocoa wrapping</a></li>
-<li><a href="#pickle-support" id="id11" name="id11">Pickle support</a></li>
-<li><a href="#nscoder-support" id="id12" name="id12">NSCoder support</a></li>
-<li><a href="#known-issues" id="id13" name="id13">Known issues</a></li>
-<li><a href="#code-cleanup" id="id14" name="id14">Code cleanup</a></li>
-<li><a href="#cleanup-examples" id="id15" name="id15">Cleanup Examples</a></li>
-<li><a href="#performance-tuning-testing" id="id16" name="id16">Performance tuning/testing</a></li>
-<li><a href="#add-freelists" id="id17" name="id17">Add freelists</a></li>
-<li><a href="#links-to-apple-documentation" id="id18" name="id18">Links to Apple documentation</a></li>
-<li><a href="#implement-more-of-nsmutabledictionary-in-oc-pythondictionary" id="id19" name="id19">Implement more of NSMutableDictionary in OC_PythonDictionary</a></li>
-<li><a href="#clean-up-oc-pythonobject" id="id20" name="id20">Clean up OC_PythonObject</a></li>
-<li><a href="#rewrite-scripts-find-raw-pointers-py" id="id21" name="id21">Rewrite scripts/find-raw-pointers.py</a></li>
-<li><a href="#finish-refactoring-of-the-code-generator-scripts" id="id22" name="id22">Finish refactoring of the code-generator scripts</a></li>
-<li><a href="#setup-py-cleanup" id="id23" name="id23">setup.py cleanup</a></li>
-<li><a href="#nsset-vs-set" id="id24" name="id24">NSSet vs set</a></li>
-<li><a href="#python-2-4" id="id25" name="id25">Python 2.4</a></li>
-<li><a href="#nslog-stringwithformat" id="id26" name="id26">NSLog, stringWithFormat, ...</a></li>
+<li><a href="#complete-cocoa-wrapping" id="id9" name="id9">Complete Cocoa wrapping</a></li>
+<li><a href="#pickle-support" id="id10" name="id10">Pickle support</a></li>
+<li><a href="#nscoder-support" id="id11" name="id11">NSCoder support</a></li>
+<li><a href="#known-issues" id="id12" name="id12">Known issues</a></li>
+<li><a href="#code-cleanup" id="id13" name="id13">Code cleanup</a></li>
+<li><a href="#cleanup-examples" id="id14" name="id14">Cleanup Examples</a></li>
+<li><a href="#performance-tuning-testing" id="id15" name="id15">Performance tuning/testing</a></li>
+<li><a href="#add-freelists" id="id16" name="id16">Add freelists</a></li>
+<li><a href="#links-to-apple-documentation" id="id17" name="id17">Links to Apple documentation</a></li>
+<li><a href="#implement-more-of-nsmutabledictionary-in-oc-pythondictionary" id="id18" name="id18">Implement more of NSMutableDictionary in OC_PythonDictionary</a></li>
+<li><a href="#clean-up-oc-pythonobject" id="id19" name="id19">Clean up OC_PythonObject</a></li>
+<li><a href="#rewrite-scripts-find-raw-pointers-py" id="id20" name="id20">Rewrite scripts/find-raw-pointers.py</a></li>
+<li><a href="#finish-refactoring-of-the-code-generator-scripts" id="id21" name="id21">Finish refactoring of the code-generator scripts</a></li>
+<li><a href="#setup-py-cleanup" id="id22" name="id22">setup.py cleanup</a></li>
+<li><a href="#nsset-vs-set" id="id23" name="id23">NSSet vs set</a></li>
+<li><a href="#python-2-4" id="id24" name="id24">Python 2.4</a></li>
+<li><a href="#nslog-stringwithformat" id="id25" name="id25">NSLog, stringWithFormat, ...</a></li>
 </ul>
 </li>
 </ul>
 be enhanced.</p>
 <p>Unless somebody actually starts working on this GNUstep support will slowly
 fade away.</p>
-<h3><a href="#id9" name="project-templates">Project templates</a></h3>
-<ul>
-<li>Update or remove the Project Builder templates<p>I prefer updating them, by rebuilding the Xcode templates in Project Builder.</p>
-<p>This would require Python 2.3 on Jaguar.</p>
-</li>
-</ul>
-<h3><a href="#id10" name="complete-cocoa-wrapping">Complete Cocoa wrapping</a></h3>
+<h3><a href="#id9" name="complete-cocoa-wrapping">Complete Cocoa wrapping</a></h3>
 <p>We do not yet have a 100% coverage of the Cocoa API's. We also need code in
 the testsuite that checks if the function wrappers are working as expected.</p>
 <p>Not all constants and enums from Cocoa are currently wrapped.  The annotations
 please report it as a bug and/or post to pyobjc-dev about the issue.  This is
 one area we intend to improve after the release of 1.3 when our new
 wrapper-generators are in a more complete state.</p>
-<h3><a href="#id11" name="pickle-support">Pickle support</a></h3>
+<h3><a href="#id10" name="pickle-support">Pickle support</a></h3>
 <p>Objective-C objects don't support pickling.</p>
 <p>This is post-1.3 work, in general this is a hard problem because it may 
 involve object cycles that cross the Python-ObjC boundary.</p>
-<h3><a href="#id12" name="nscoder-support">NSCoder support</a></h3>
+<h3><a href="#id11" name="nscoder-support">NSCoder support</a></h3>
 <p>It might be useful to add default implementations of <code><span>encodeWithCoder:</span></code> and
 <code><span>initWithCoder:</span></code> methods to Python subclasses of Objective-C classes that 
 implement these.  Note that property list types should already be serializable
 (<code><span>int</span></code>, <code><span>long</span></code>, <code><span>unicode</span></code>, <code><span>list</span></code>, <code><span>tuple</span></code>, <code><span>dict</span></code>).</p>
 <p>See also <cite>Pickle support</cite>.</p>
-<h3><a href="#id13" name="known-issues">Known issues</a></h3>
+<h3><a href="#id12" name="known-issues">Known issues</a></h3>
 <p>It is impossible to support methods with a variable number of arguments in the
 generic code (you have to re-implement almost all of the logic of these 
 methods in order to know how many and which types of arguments are expected).
 we should provide custom wrappers, otherwise we should document alternatives.</p>
 <p>Limitations such as the above should be clearly documented elsewhere, these
 are not necessarily TODO items.</p>
-<h3><a href="#id14" name="code-cleanup">Code cleanup</a></h3>
+<h3><a href="#id13" name="code-cleanup">Code cleanup</a></h3>
 <ul>
 <li>Check all error/exception messages</li>
 <li>Check/cleanup error handling</li>
 <li>Finish in-code documentation for the C code</li>
 </ul>
-<h3><a href="#id15" name="cleanup-examples">Cleanup Examples</a></h3>
+<h3><a href="#id14" name="cleanup-examples">Cleanup Examples</a></h3>
 <p>The CurrencyConverter example should be removed, this should be the same as the
 final step of the tutorial. It isn't at the moment because additional cruft in
 the example.</p>
 <li>how to integrate with MacPython</li>
 <li>how to use PIL with Cocoa</li>
 </ul>
-<h3><a href="#id16" name="performance-tuning-testing">Performance tuning/testing</a></h3>
+<h3><a href="#id15" name="performance-tuning-testing">Performance tuning/testing</a></h3>
 <p>Design and implement a set of performance tests for the bridge. Use this to 
 investigate and fix any possible performance problems.</p>
-<h3><a href="#id17" name="add-freelists">Add freelists</a></h3>
+<h3><a href="#id16" name="add-freelists">Add freelists</a></h3>
 <p>PyObjCSelector objects and PyObjCObject objects are created on
 a regular basis, we should check if using freelists would speed this up. See
 also <cite>Performance tuning/testing</cite>.</p>
 <p>NOTE: first add performance tests then experiment with freelists.</p>
-<h3><a href="#id18" name="links-to-apple-documentation">Links to Apple documentation</a></h3>
+<h3><a href="#id17" name="links-to-apple-documentation">Links to Apple documentation</a></h3>
 <p>Links to Apple documentation are not stable, can we add a layer of indirection
 here, e.g. link to the PyObjC website that will redirect to the right
 location?</p>
 <p>We should also provide links to locally installed documentation,
 especially in the documentation that will be installed on the users machine.</p>
-<h3><a href="#id19" name="implement-more-of-nsmutabledictionary-in-oc-pythondictionary">Implement more of NSMutableDictionary in OC_PythonDictionary</a></h3>
+<h3><a href="#id18" name="implement-more-of-nsmutabledictionary-in-oc-pythondictionary">Implement more of NSMutableDictionary in OC_PythonDictionary</a></h3>
 <p>The implementation of OC_PythonDictionary is very minimal, we should add
 additional methods in the NSMutableDictionary interface if those can be 
 implemented efficiently. The default implementation will take care of the
 <p>And the same is true of OC_PythonArray</p>
 <p>In both cases we shouldn't do this unless we can measure the difference in
 performance.</p>
-<h3><a href="#id20" name="clean-up-oc-pythonobject">Clean up OC_PythonObject</a></h3>
+<h3><a href="#id19" name="clean-up-oc-pythonobject">Clean up OC_PythonObject</a></h3>
 <p>The code is a mess.</p>
-<h3><a href="#id21" name="rewrite-scripts-find-raw-pointers-py">Rewrite scripts/find-raw-pointers.py</a></h3>
+<h3><a href="#id20" name="rewrite-scripts-find-raw-pointers-py">Rewrite scripts/find-raw-pointers.py</a></h3>
 <p>This is a script for finding 'difficult' methods. The script should be 
 refactored to make it easier to create readable reports.</p>
-<h3><a href="#id22" name="finish-refactoring-of-the-code-generator-scripts">Finish refactoring of the code-generator scripts</a></h3>
+<h3><a href="#id21" name="finish-refactoring-of-the-code-generator-scripts">Finish refactoring of the code-generator scripts</a></h3>
 <ol type="1">
 <li>Change code-generator scripts to use loadBundleFunctions, etc.</li>
 <li>Move the code-generator scripts to <code><span>PyObjCTools</span></code>, to make it easier
 for others to generate wrappers.</li>
 <li>Install <code><span>pyobjc-api.h</span></code>.</li>
 </ol>
-<h3><a href="#id23" name="setup-py-cleanup">setup.py cleanup</a></h3>
+<h3><a href="#id22" name="setup-py-cleanup">setup.py cleanup</a></h3>
 <ul>
 <li>Use 'WrapperGenerator.py', probably need to create a custom build action
 for that.</li>
 </ul>
-<h3><a href="#id24" name="nsset-vs-set">NSSet vs set</a></h3>
+<h3><a href="#id23" name="nsset-vs-set">NSSet vs set</a></h3>
 <p>Check if it is possible to wrap <code><span>NSSet</span></code> using <code><span>set</span></code> (and v.v.).</p>
 <p>Only implement this when it is possible to convert without loss of information.</p>
 <p><strong>Ronald, 20050130</strong>: <i>converting</i> is not an option: PyObjC takes care to
 preserve the identity of ObjC objects when passed through python. This is 
 necessary for at least some APIs.   Furthermore, both <code><span>NSSet</span></code> and 
 <code><span>__builtin__.set</span></code> are mutable!</p>
-<h3><a href="#id25" name="python-2-4">Python 2.4</a></h3>
+<h3><a href="#id24" name="python-2-4">Python 2.4</a></h3>
 <p>Python 2.4 introduces a decorator syntax. Add convenience functions that
 make it easier to use decorators with PyObjC.</p>
 <p>Also add example programs using decorators. Actually, first add the example(s)
         def myIntMethod_(self, value):
                 pass
 </pre>
-<h3><a href="#id26" name="nslog-stringwithformat">NSLog, stringWithFormat, ...</a></h3>
+<h3><a href="#id25" name="nslog-stringwithformat">NSLog, stringWithFormat, ...</a></h3>
 <p>Functions and methods that use format strings are not properly wrapped. Fix
 that.</p>
 </body>
 Unless somebody actually starts working on this GNUstep support will slowly
 fade away.
 
-Project templates
-.................
-
-* Update or remove the Project Builder templates
-
-  I prefer updating them, by rebuilding the Xcode templates in Project Builder.
-
-  This would require Python 2.3 on Jaguar.
-
 Complete Cocoa wrapping
 .......................
 
 </li>
 <li><a href="Xcode-Templates.html">Xcode Python templates</a><p>Describes the PyObjC Xcode templates.</p>
 </li>
-<li><a href="ProjectBuilder-Templates.html">Project Builder Python templates</a><p>Describes the PyObjC Project Builder templates.</p>
-</li>
-<li><a href="ProjectBuilder-SyntaxHighlighting.html">Project Builder Python syntax highlighting</a><p>Describes the Project Builder syntax highlighting for Python.</p>
-</li>
 </ul>
 </body>
 </html>
 
   Describes the PyObjC Xcode templates.
 
-* `Project Builder Python templates`_
-
-  Describes the PyObjC Project Builder templates.
-
-* `Project Builder Python syntax highlighting`_
-
-  Describes the Project Builder syntax highlighting for Python.
-
 .. _`Xcode Python templates`: Xcode-Templates.html
 
-.. _`Project Builder Python syntax highlighting`: ProjectBuilder-SyntaxHighlighting.html
-
-.. _`Project Builder Python templates`: ProjectBuilder-Templates.html
-
 .. _`An introduction to PyObjC`: intro.html
 
 .. _`Python classes and Objective-C code`: classes.html

Doc/structure.html

 <dt>Installer Package/</dt>
 <dd><p>Resources used for building the Apple Installer packages.</p>
 </dd>
-<dt>ProjectBuilder Extras/</dt>
-<dd><p>Project Builder templates and syntax specifications for PyObjC development.</p>
-</dd>
 <dt>Xcode/</dt>
 <dd><p>Xcode templates for PyObjC development.</p>
 </dd>

Doc/structure.txt

 Installer Package/
   Resources used for building the Apple Installer packages.
 
-ProjectBuilder Extras/
-  Project Builder templates and syntax specifications for PyObjC development.
-
 Xcode/
   Xcode templates for PyObjC development.
 

Modules/objc/pyobjc.h

  * Central include file for PyObjC. 
  */
 
-#define OBJC_VERSION "1.3.5"
+#define OBJC_VERSION "1.3.9"
 
 // Loading in AppKit on Mac OS X 10.3 results in
 // a bit less than 1500 classes.
 <body>
 <h2>PyObjC NEWS</h2>
 <p>An overview of the relevant changes in new, and older, releases.</p>
+<h2><a name="version-1-4-2005">Version 1.4 (2005-??-??)</a></h2>
+<ul>
+<li>Removed all references to Project Builder</li>
+<li>Mac OS X 10.2 (Jaguar) no longer supported</li>
+</ul>
 <h2><a name="version-1-3-5-2005-05-18">Version 1.3.5 (2005-05-18)</a></h2>
 <ul>
 <li>Importing objc now ensures that Foundation is multi-threaded, previously
 
 An overview of the relevant changes in new, and older, releases.
 
+Version 1.4 (2005-??-??)
+------------------------
+
+- Removed all references to Project Builder
+
+- Mac OS X 10.2 (Jaguar) no longer supported
+
 Version 1.3.5 (2005-05-18)
 --------------------------