Cocoa-based Interfaces on Mac OS X

Using PyObjC, the Python-Objective C bridge, it is possible to create native Cocoa Mac OS X applications in pure Python. While Cocoa interfaces are not cross-platform, they have an advantage over cross-platform interfaces (such as WxPython GUIs) in that they are fast and have a native look and feel, which is likely to be important to Mac users.

This page discusses issues related to Cocoa development with PyObjC.

 

Contents

  1. Cocoa-based Interfaces on Mac OS X
  2. Cocoa expects an MVC design pattern
    1. What's the model?

 

Cocoa expects an MVC design pattern

This is potentially a great asset for a Django-based project, but it raises some questions about how to develop a Cocoa interface, especially when developing it in parallel with other GUIs. Specifically:

 

What's the model?

With a Cocoa-based interface, the "view" (template in Django terms) is the actual presentation to the user — a collection of controls and object relationships stored in a NIB (NeXTstep interface builder) file. The controller ("view" is Django terms) is a custom class we'll write to control that presentation and glue it to application-tier code. In the terminology of the ../ClassHierarchy page, controllers would be classes such as TitleEditCocoaForm . But what should be considered the "model" for a Cocoa-based GUI?

There are a few possibilities. First of all, we can simply use Django models. The problem here is that Django models don't have the interface that Cocoa expects (for example, they don't have explicit setter and getter methods for each attribute), so we would have to provide this interface either with a mixin class or via inheritance. In either case, we aren't using the Django model directly, and we're putting extra code in the data tier which is specific to a particular kind of presentation (!!).

If, on the other hand, we use some sort of proxy as the model, a class which communicates with the Django models but which can be exposed to Cocoa via PyObjC, this problem disappears. But then we have a picture where we have an entire MVC design pattern embedded in what is supposed to be just the presentation tier of the larger Django-based application. Moreover, since the other GUI toolkits aren't likely to behave this way, this idea would be a significant departure from the overall conception of how the application works.

Finally, it may make sense to consider that the Cocoa-based interface rolls its "models" and "controllers" into the same class. That is, a controller class like TitleEditCocoaForm contains both the methods called as a result of user events as well as references to the particular Django model objects it works with. The controller class will be responsible for communicating directly with the application tier. On this picture, the "model" is still the Django model from the perspective of the overall application, but from a perspective within the Cocoa-based UI, we can consider the controller class to be "its own" model.