Pyobjc

---------------------------

- Fix a number of bugs found in 1.0rc1.

---------------------------

- Better support for the NSKeyValueCoding protocol. The module
``PyObjCTools.KeyValueCoding`` provides a python interface that makes it
possible to use key-value coding with python objects as well as
Objective-C objects. Key-Value Coding also works as one would expect with
Python objects when accessing them from Objective-C (both for plain Python
objects and Python/Objective-C hybrid objects).

- objc.pyobjc_unicode objects are now pickled as unicode objects, previously
the couldn't be pickled or were pickled as incomplete objects (protocol
version 2).

- Pickling of ObjC objects never worked, we now explicitly throw an exception
if you try to pickle one: pickle protocol version 2 silently wrote the
incomplete state of objects to the pickle.

- The default repr() of ObjC objects is now the result of a call to the
``description`` method. This method is not called for uninitialized objects,
because that might crash the interpreter; we use a default implementation
in that case.

- A minor change to the conversion rule for methods with output arguments
(pointers to values in ObjC, where the method will write through the pointer).
If the method has 'void' as its return type, we used to return a tuple where
the first value is always None. This first element is no longer included,
furthermore if the method has only 1 output argument we no longer return
a tuple but return the output value directly (again only if the method has
'void' as its return type).

This is a backward incompatible change, but there are not many of such
methods.

- Another backward incompatible change is a minor cleanup of the names in
the ``objc`` module. The most significant of these is the change from
``recycle_autorelease_pool`` to ``recycleAutoreleasePool``. The other
changed names are internal to the bridge and should not be used in other
code.

- The interface of Foundation.NSFillRects changed, it now has an interface
that is consistent with the rest of the bridge.

--------------------------

- More tutorials

Two new tutorials were added: 'Adding Python code to an existing ObjC
application' and 'Understanding existing PyObjC examples'. The former
explains how you can use Python to add new functionality to an already
existing Objective-C application, the latter explains how to understand
PyObjC programs written by other people.

- More examples

Three examples were added: DotView, ClassBrowser and PythonBrowser,
respectively showing the use of a custom NSView, NSBrowser and
NSOutlineView. PythonBrowser is reusable, making it trivial to add an
object browser to your application.

- Support for MacOS X 10.1

It is now possible to build PyObjC on MacOS X 10.1, with full access to
the Cocoa API's on that platform.

Note: The port to MacOS X 10.1 is not as well supported as the 10.2 port.
The developers do not have full-time access to a MacOS X 10.1 system.

- Support for the WebKit framework, included with Safari 1.0.

If you build PyObjC from source you will have to build on a system that has
the WebKit SDK installed to make use of this. Note that the additional
functionality will only be usable on systems that have Safari 1.0 installed,
however as long as you don't use the additional functionality it is safe
to run a 'WebKit-enabled' PyObjC on systems without Safari 1.0.

- It is no longer necessary to specify which protocols are implemented by

a class, this information is automatically deduced from the list of implemented
methods. You'll still a runtime error if you implement some methods of a
protocol and one of the unimplemented methods is required.

- Support for "toll-free bridging" of Carbon.CF types to Objective-C objects.

It is now possible to use instances of Carbon.CF types in places where
Objective-C objects are expected. And to explicitly convert between the two.

Note: this requires Python 2.3.

- Better integration with MacPython 2.3:

* ``NSMovie.initWithMovie_`` and ``NSMovie.QTMovie`` now use ``QT.Movie``
objects instead of generic pointer wrappers.

* ``NSWindow.initWithWindowRef_`` and ``Window.windowRef`` now use
``Carbon.Window`` objects instead of generic pointer wrappers.

* Methods returning CoreFoundation objects will return MacPython objects,
and likewise, methods with CoreFoundation arguments will accept MacPython
objects.

- It is now possible to write plugin bundles, such as preference panes for
use in System Preferences, in Python. See Examples/PrefPanes for an example
of this feature.

- The methods ``pyobjcPopPool`` and ``pyobjcPushPool`` of ``NSAutoreleasePool``
are deprecated. These were introduced when PyObjC did not yet support the
usual method for creating autorelease pools and are no longer necessary.

- Improved unittests, greatly increasing the confidence in the correctness
of the bridge.

- All support for non-FFI builds has been removed.

- Object state is completely stored in the Objective-C object. This has no
user-visible effects, but makes the implementation a lot easier to
comprehend and maintain.

- As part of the previous item we also fixed a bug that allowed addition of
attributes to Objective-C objects. This was never the intention and had
very odd semantics. Pure Objective-C objects not longer have a __dict__.

- Weakrefs are no longer used in the implementation of the bridge. Because
the weakrefs to proxy objects isn't very useful the entire feature has
been removed: It is no longer possible to create weakrefs to Objective-C
objects.

NOTE: You could create weakrefs in previous versions, but those would
expire as soon as the last reference from Python died, *not* when the
Objective-C object died, therefore code that uses weakrefs to Objective-C
objects is almost certainly incorrect.

- Added support for custom conversion for pointer types. The end result is that
we support more Cocoa APIs without special mappings.

- The generator scripts are automatically called when building PyObjC. This
should make it easier to support multiple versions of MacOS X.

----------------------------

- Here again, supporting GNU_RUNTIME and GNUstep Base! On my new Linux
box I can finally test the module against them: I installed the
latest snapshot of gstep-core, that contains the base library
too. Given a sane GNUstep env (GNUSTEP_XXX env vars), you should be
able to build a static ObjC-ized interpreter by::

o Adjusting Setup, commenting out NeXT definition and enabling GNU
ones;
o make -f Makefile.pre.in boot
o make static

---------------------------

- OC_Pasteboard.[hm], OC_Stream.[mh] and ObjCStreams.m are definitively gone.

- OC_PythonObject derives from NSProxy.

----------------------------

- Tons of changes, retargeting the core functionality around the
OpenSTEP API. This release basically matches the previous one
in terms of functionalities, but is should be closer to GNUstep.

- OC_Streams and OC_Pasteboard aren't supported, I've not yet decided
if they are needed anymore.

- Updated LittleButtonedWindow demo.