PyObjC NEWS

More fine-grained multi-threading support

Xcode templates use a smarter embedded main program

Add support for WebObjects 4.5 (a one-line patch!)

Add a PackageManager clone to the Examples directory

Add better support for NSProxy

This makes it possible to use at Distributed Objects, although this feature has not received much testing

Function 'objc.protocolNamed' is the Python equivalent of the @protocol expression in Objective-C.

Add several new examples

Fixes some regressions in 1.1 w.r.t. 1.0

Add Xcode templates for python files

You can now select a new python file in the 'add file...' dialog in Xcode

Fix installer for Panther: the 1.1a0 version didn't behave correctly

There is now an easier way to define methods that conform to the expectations of Cocoa bindings:

class MyClass (NSObject):
        def setSomething_(self, value):
                pass
        setSomething_ = objc.accessor(setSomething_)
        def something(self):
                return "something!"
        something = objc.accessor(something)

It is not necessary to use objc.accessor when overriding an existing accessor method.

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 in Foundation and NSAffineTransformStruct in AppKit.

This means you can now access the x-coordinate of a point as aPoint.x, accessing aPoint[0] is still supported for compatibility with older versions of PyObjC.

It is still allowed to use tuples, or other sequences, to represent Objective-C structs.

NOTE: This has two side-effects that may require changes in your programs: the values of the types mentioned above are no longer immutable and cannot be used as keys in dicts or elements in sets. Another side-effect is that a pickle containing these values created using this version of PyObjC cannot be unpickled on older versions of PyObjC.

This version adds support for NSDecimal. This is a fixed-point type defined in Cocoa.

NSDecimalNumbers are no longer converted to floats, that would loose information.

If an Objective-C method name is a Python keyword you can now access it by appending two underscores to its name, e.g. someObject.class__().

The same is true for defining methods, if you define a method raise__ in a subclass of NSObject it will registered with the runtime as 'raise'.

NOTE: Currently only 'class' and 'raise' are treated like this, because those are the only Python keywords that are actually used as Objective-C method names.

Experimental support for instanceMethodForSelector: and methodForSelector:. This support is not 100% stable, and might change in the future.

Backward incompatible change: class methods are no longer callable through the instances.

Integrates full support for MacOS X 10.3 (aka Panther)

Adds a convenience/wrapper module for SecurityInterface

It is now safe to call from Objective-C to Python in arbitrary threads, but only when using Python 2.3 or later.

Fixes some issues with passing structs between Python and Objective-C.

Uses the Panther version of NSKeyValueCoding, the Jaguar version is still supported.

method updateNSString of objc.pyobjc_unicode is deprecated, use create a new unicode object using unicode(mutableStringInstance) instead.

NSAppleEventDescriptor bridged to Carbon.AE

LibFFI is used more aggressivly, this should have no user-visible effects other than fixing a bug related to key-value observing.

Adds a number of new Examples:

• OpenGLDemo

  Shows how to use OpenGL with PyObjC

• SillyBallsSaver

  Shows how to write a screensaver in Python. Requires a framework install of Python (that is, MacOS X 10.3 or MacPython 2.3 on MacOS X 10.2).

• Twisted/WebServicesTool

  Shows how to integrate Twisted (1.1 or later) with Cocoa, it is a refactor of the WebServicesTool example that is made much simpler by using Twisted.

• Twisted/WebServicesTool-ControllerLayer

  Shows how to integrate Twisted (1.1 or later) with Cocoa, it is a refactor of the WebServicesTool example that is made much simpler by using Twisted as it does not need threads. This one also uses NSController and therefore requires MacOS X 10.3.

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 unitialized 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 usuable 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 automaticly 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 suppport 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 automaticly called when building PyObjC. This should make it easier to support multiple versions of MacOS X.

This version includes numerous bugfixes and improvements.

The module AppKit.NibClassBuilder has been moved to the package PyObjCTools.

Usage of libFFI (http://sources.redhat.com/libffi) is now mandatory. The setup.py gives the impression that it isn't, but we do not support non-FFI builds.

We actually have some documentation, more will be added in future releases.

There are more Project Builder templates (see 'Project Templates').

The InterfaceBuilder, PreferencePanes and ScreenSaver frameworks have been wrapped.

Management of reference counts is now completely automatic, it is no longer necessary to manually compensate for the higher reference count of objects returned by the alloc, copy and copyWithZone: class methods.

Various function and keyword arguments have been renamed for a better integration with Cocoa. A partial list is of the changed names is:

objc.lookup_class -> objc.lookUpClass
objc.selector arguments/attributes:
        is_initializer -> isInitializer
        is_allocator -> isAlloc
        donates_ref -> doesDonateReference
        is_required -> isRequired
        class_method -> isClassMethod
        defining_class -> definingClass
        returns_self -> returnsSelf
        argument_types -> argumentTypes
        return_type -> returnType
objc.get_class_list -> objc.getClassList

On Python 2.2, objc.YES and objc.NO are instances of a private boolean type, on Python 2.3 these are instances of the builtin type bool.

Because we now use libFFI a large amount of code could be disabled. The binaries are therefore much smaller, while we can now forward messages with arbitrary signatures (not limited to those we thought of while generating the static proxies that were used in 0.8)

Better support for APIs that use byte arrays are arguments or return values. Specifically, the developer can now manipulate bitmaps directly via the NSBitmapImageRep class, work with binary data through the NSData class, and very quickly draw points and rects via NSRectFillList()

We added a subclass of unicode that is used to proxy NSString values. This makes it easily possible to use NSString values with Python APIs, while at the same time allowing access to the full power of NSString.

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

Accepts a struct.pack() string for pointer arguments, but...

... New methods on ObjCMethod: .pack_argument and .unpack_argument: these should be used whenever an ObjC method expects a passed-by-reference argument; for example, on NeXTSTEP [View getFrame:] expects a pointer to an NXRect structure, that it will fill with the current frame of the view: in this case you should use something similar to:

framep = aView.getFrame__.pack_argument (0)
aView.getFrame__ (framep)
frame = aView.getFrame__.unpack_argument (0, framep)

Correctly handle pointer arguments.

New syntax to get a class: ObjC.runtime.NameOfClass

New syntax aliasing .new(): SomeClass()

New Demo: LittleButtonedWindow, that tests points above.

What follow is the recipe to get PyObjC dynamically loadable on NeXTSTEP:

• apply the patch in Misc/INSTALL.PyObjC to Python/importdl.c

• modify Python/Makefile adding the switch -ObjC to the importdl.o build rule:

  importdl.o:   importdl.c
    $(CC) -ObjC -c $(CFLAGS) -I$(DLINCLDIR) $(srcdir)/importdl.c
  

• modify Modules/Setup moving the PyObjC entry suggested above AFTER *shared*, and remove -u libNeXT_s -lNeXT_s from it.

• run make: this will update various files, in particular Modules/Makefile.

• modify Modules/Makefile adding -u libNeXT_s -lNeXT_s to SYSLIBS:

  SYSLIBS=      $(LIBM) $(LIBC) -u libNeXT_s -lNeXT_s
  

• run make again