[Openmcl-devel] Using Cocoa with MCL

[Randall Beer]

> I would like (for lots of reasons) to make it into something that 
> people
> could use to do actual work, and to improve the interoperability 
> between
> OpenMCL and Cocoa so that people could more easily develop real 
> applications
> with rich GUIs.
>
> [...]
>
> I've occasionally heard other people mention that they're working
> on some aspects of improving and extending the Cocoa support, and
> there have been some suggestions made on this list for making the
> business of writing Cocoa programs in OpenMCL a less tedious and
> error-prone process than it currently is.

Since I'm one of the people who expressed an interest in this a few 
months ago, I felt compelled (shamed?) into replying.

There are a number of technical issues that need to be worked out in 
order to better integrate Cocoa into Lisp.  But I think a prior 
question is What kind of Lisp interface would be necessary for more 
people to start doing serious GUI development in OpenMCL? There are 
some obvious things, but beyond these there are genuine design choices.

For example, what level of access to Cocoa should be provided in Lisp?  
At one extreme, there is fairly direct access to ObjC classes, objects 
and methods.  Gary has basically already provided this, although 
certain ObjC details (like memory management, type checking, and 
conversion between Lisp data and ObjC data)  could probably be hidden, 
and a bit more syntactic sugar could probably be provided.  This has a 
number of advantages: (1) It is very lightweight; (2) It corresponds 
rather directly to ObjC programming, so that, for example, examples 
from Cocoa programming books could be fairly directly translated; (3) 
It will automatically track any changes and improvements that Apple 
makes to Cocoa.  On the other hand, it feels much more like foreign 
function programming than it does Lisp programming, with constant 
switching between Lisp and ObjC views of the world.

At the other extreme, ObjC could be hidden completely and a CLOS 
interface like the GUI classes in MCL could be implemented on top of 
Cocoa. This has the advantage of being very Lisp-like, but the 
disadvantages that it will require a lot more work, the direct 
correspondence with Cocoa is lost and tracking Cocoa changes will 
require a continuing implementation effort on the CLOS interface.

Of course, there are various options between these two extremes.  One 
could imagine a CLOS hierarchy that parallels the Cocoa hierarchy, with 
behind-the-scenes glue code that keeps the two worlds in sync. 
Technical issues aside, there are many design issues with how to 
accomplish such an integration as smoothly as possible.  For example, 
do we want to write

[[NSWindow alloc]
     initWithContentRect: graphicsRect
     styleMask: NSTitledWindowMask |  NSClosableWindowMask | 
NSMiniaturizableWindowMask
     backing: NSBackingStoreBuffered
     defer: No]]
[w setTitle: @"My Window"]

as (essentially Gary's current code)

[[(@class "NSWindow") "alloc"]  
"initWithContentRect:styleMask:backing:defer:"
      graphicsRect
      (bit-ior $NSTitledWindowMask
                   $NSClosableWindowMask
                   $NSMiniaturizableWindowMask)
      $NSBackingStoreBuffered
     $No]]
[w "setTitle:" @"My Window"]

or (with a special reader for #\[, with NSWindow a CLOS class )

[[NSWindow alloc]
     initWithContentRect: graphicsRect
     styleMask: (bit-ior NSTitledWindowMask
                                      NSClosableWindowMask
                                      NSMiniaturizableWindowMask)
     backing: NSBackingStoreBuffered
     defer: No]]
[w setTitle: "My Window"]

or (a fairly direct Lispification of the ObjC names and method 
structure)

(make-instance 'ns-window
     :init-with-content-rect graphicsRect
     :styleMask
     (bit-ior *ns-titled-window-mask*
                  *ns-closable-window-mask*
                  *ns-miniaturizable-window-mask*)
     :backing *ns-backing-store-buffered*
     :defer nil)
(send w :set-title "My Window")

or (a major Lispification of the ObjC names and method structure)

(make-instance 'ns-window :content-rect graphicsRect)
(set-title w "My Window")

Each of these has different different implications for the "feel" of 
Lisp/Cocoa integration.

What do people think? What is the minimum GUI level it would take to 
get people to, say, write a full-featured GUI editor or debugger for 
OpenMCL?  What kind of a Cocoa interface would make porting CLIM to 
OpenMCL easier?  Hamilton Link's inspector? Cocoa applications that 
people would like to port to or develop in Lisp?


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel