[Openmcl-devel] Cocoa

[Hamilton Link]

Having written the cocoa-inspector, and not a lot else ...

(lengthy interruption -- please try to use it and tell me what's wrong 
with it, I'm in the process of designing a new better version and would 
like user input! Just require cocoa-inspector and call ccl::cinspect on 
whatever object you're interested in. clicking on a field's value in 
the lower half lets you put in a new value (a lisp form that gets 
evaluated, actually), and double-clicking in the top half opens up a 
new inspector. I already have some input from myself and a couple of 
people, but more use cases and ideas of things you'd like an inspector 
to do are always welcome)

Anyway, having written the cocoa inspector, the bulk of the pain is 
discovering which gui widgets do what and have xyz API and handle abc 
events, and the rest of it is converting t/nil and fixnums and strings 
and whatnot. The latter half should be straightforward to fix with a 
thin wrapper around the Cocoa APIs and data structures, possibly even a 
MOP-assisted one (since ObjC is introspective to some degree) as I have 
often considered but never had time to explore.

The main reason I haven't done more than I have is time constraints, 
rather than usability -- and until I use it more I'd hesitate to 
suggest a lot of changes. In the process of redoing the cocoa 
inspector, I figure I'll apply lessons learned from the last one to 
abstract away concerns for the widget particulars for the next one. 
Maybe other people would entertain success with this approach, I don't 
know, but...

what I personally propose is people carve out a niche for themselves in 
terms of some dinky little utility for OpenMCL and figure out what 
would and wouldn't work for you (people could beef up the editor or 
slap together a process info viewer or whatever). If OpenMCL utilities 
aren't your thing, do something for your own purposes. Baby steps and a 
little experience starting interfacing into ObjC will, I think, lead to 
a much better result than jumping into CLIM straightaway, but that 
could be that my POV is skewed by not having a great deal of interface 
development experience.

just MHO,
hamilton

On Tuesday, February 4, 2003, at 06:55 PM, Randall Beer wrote:

>> I think that the examples show that it's possible to write fairly
>> interesting Cocoa programs without writing a whole lot of code.
>>
>> I think that the fact that the examples have pretty much stood
>> still for several months might indicate that there needs to be a
>> layer or two above the reader macros and glue that exist now.
>> (It's neat to be able to write code in what looks like a hybrid
>> of lisp and ObjC syntax, but I'd like to be able to write lisp
>> code that provided a user interface and ignore all of the low-level
>> details of dealing with the ObjC/Cocoa runtime.)
>
> Gary,
>
> I strongly agree that it would be very nice to have a Lisp layer over 
> the details of ObjC/Cocoa. What do you think the best way to structure 
> such a layer is?
>
> CLIM is obviously one possibility.  Another possibility is something 
> like the view, window, etc. classes in MCL reimplemented in Cocoa.
>
> I've been wondering if there might not be a way to automatically 
> provide a Lisp "mirror" for Cocoa.  The idea is to use the parsing of 
> the Cocoa interface files that is already done to define a set of CLOS 
> classes and methods that parallel those in Cocoa.  If this could be 
> done, then we could write something like
>
> (setq w (make-instance 'NSWindow))
> (setTitle w "My Window")
> (makeKeyAndOrderFront w)
>
> instead of
>
> [[(@class "NSWindow") "alloc"] "init"]
> [wptr "setTitle:" :address (%make-nsstring "My Window")]
> [wptr "makeKeyAndOrderFront:" :address (%null-ptr)]
>
> There are obvious case issues here.  Perhaps a method of the form 
> "makeKeyAndOrderFront" could be automatically turned into a Lisp-style 
> symbol such as MAKE-KEY-AND-ORDER-FRONT, "setTitle" could be 
> transformed into SET-TITLE, etc.
>
> Making this work would require that any Cocoa mirror object inherit 
> from a special NSObject CLOS class and possibly some MOP programming.  
> The key thing would be that defining a new CLOS class that inherits 
> from an existing mirror object would create the necessary ObjC class 
> structure, making an instance of one of these Cocoa mirror objects 
> would create the corresponding ObjC instance structure. Defining a 
> method on one of the mirror classes would create an ObjC method in the 
> corresponding ObjC class, accessing a slot in a mirror object would 
> return a corresponding Lisp object, etc.
>
> Undoubtedly, there are many difficult issues that would have to be 
> addressed to make this work.  For example, how to keep the memory 
> allocation and deallocation syncronized between Lisp and ObjC?  The 
> advantage would be that this mirror approach, if it were feasible, 
> would bypass the effort involved in writing an entire CLOS interface 
> to Cocoa and would automatically inherit new features as Apple 
> releases them
>
> Just a thought.
>
> Randy
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>



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