[Openmcl-devel] Using Cocoa with MCL
helink at sandia.gov
Mon May 12 11:08:55 PDT 2003
On Thursday, May 8, 2003, at 06:51 PM, Randall Beer wrote:
> On Thursday, May 8, 2003, at 05:34 PM, Hamilton Link wrote:
>> One more thing -- it would be nice to be able to use the Interface
>> Builder. If we do build a super-fancy wrapper around all of Cocoa, it
>> would be nice to get Interface Builder to automagically generate a
>> portion of the necessary lisp code based on me (or whoever) claiming
>> to make subclasses and Outlets, etc.
>> I don't know if this is possible, mind you, but I got the impression
>> that it was possible to define new dialects for the boilerplate
>> Also I am under the impression that it's possible to define new
>> custom widgets under Cocoa that do various fancy things, like radio
>> dials or whatever. Being able to dynamically pull in such a library
>> (defining a new widget class) and build the lisp wrapper code for
>> them would be good, if we don't get it for free, which we might if we
>> do this properly.
> If a (semi)automatically generated Cocoa interface were done properly,
> then nib files and new Cocoa classes should be loadable. I don't know
> offhand what would be involved in getting Interface Builder to
> generate Lisp code, but that wasn't quite what I had in mind. It might
> be an option, though.
Seems like Interface Builder will probably always want to generate NIB
files that refer to ObjC classes it thinks exist. There's a number of
ways I can think of we might address this, none of which are probably
easy, maybe someone else has a better idea...
1) Set up lisp to automatically revamp NIB files to refer to the
lisp-mapped objc classes (this is probably easy enough to do). The
problem is all the outlets and connections you'd like to set up with IB
won't really be set-upable, so what about
2) Based on specialization in lisp's world, create an ObjC library file
(or several) that can be added to an IB project that will tell IB about
all the potential connectors and classes it can generate NIB files for,
have the NIB files generated with all this information, and have Lisp
take over the loading process. This doesn't seem very
rapid-prototype-supportish to me since you have a lisp development bit
that has to preceed any IB use, so what about
3) Based on specialization and addition of outlets, etc. in IB, have it
generate lisp code (rather than java or objc etc, i.e. we'd define a
new dialect) and NIB files that openmcl can use to extend the lisp
class hierarchy, plug in to the right places in ObjC, and manage the
NIB loading process. I don't even know if this is possible, but it
seems like the ideal situation we could strive for.
>> Also while I'm dreaming, I'd like a pony.
> Is that a subclass of NSObject? :-)
No, NSPony is a subclass of NSImaginaryObject, a peer of NSObject. I
think memory allocation is a little different for NSIOs.
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel