[Openmcl-devel] Using Cocoa with MCL

[Hamilton Link]

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 
>> generator.
>>
>> 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.

h

>
>> Also while I'm dreaming, I'd like a pony.
>
> Is that a subclass of NSObject? :-)
>
> Randy

No, NSPony is a subclass of NSImaginaryObject, a peer of NSObject.  I 
think memory allocation is a little different for NSIOs.
h



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