[Openmcl-devel] Missing methods/constants from Cocoa bridge

[Gary Byers]

Just to follow up on this a little: I installed 10.4 interfaces on a
system running 10.4.6, built the demo Cocoa IDE (via
"cocoa-application.lisp"), dragged the resulting application bundle
over to a 10.3.9 system, and double-clicked on it.

It came up and displayed a listener.  So far, so good; what I was
most curious about were cases involving classes that:

- existed when the application was built on 10.4
- were declared to exist (and have other properties ...) in the
   10.4 interfaces, and
- didn't exist in the 10.3.9 Cocoa libraries.  (Like NSDatePicker,
   for instance ...)

? (find-class 'ns:ns-date-picker)
#<OBJC:OBJC-CLASS NS:NS-DATE-PICKER (#x0)>

Note that the address in the printed representation of the class is 0 
(a "real" class imported from one of the Cocoa libraries would probably/
usually have an address whose high nibble is #xA), so

? (ccl:%null-ptr-p *)
T

Other missing ObjC classes were also (unique) NULL pointers:

? (find-class 'ns:ns-text-table)
#<OBJC:OBJC-CLASS NS:NS-TEXT-TABLE (#x0)>

Sending an "alloc" message to a missing class returns a NULL pointer,
and (in general) it's pretty easy to detect the presence of these
things and signal errors on attempts to use them.  If the application
doesn't try to use them (where "use" means roughly "subclass or
define methods on), they seem to be pretty harmless.

What this all means is that it's possible to use Tiger (in general,
the latest) interfaces and still run on older systems (Panther, at
least) as long as the application doesn't actually use Tiger- specific
functionality.  That seems to largely eliminate the need to be able to
support multiple interface hierarchies (what I was rambling on about
in the message below) and that seems like a good thing ...

On Wed, 14 Jun 2006, Gary Byers wrote:

> I strongly suspect that the missing things are missing from the
> Panther-vintage .h files from which the interfaces bundled with 1.0
> were derived.
>
> XCode's approach to this is to install separate hierarchies under
> /Developer/SDKs/ (each of which acts something like "ccl:headers;"
> does under DarwinPPC32.)  I'm not sure that I really like that idea,
> but don't know of anything (much) better.  (The translation of that
> idea is that there'd be separate "root" directories under "ccl:headers;",
> and if you wanted to use something other than the default root you'd
> say something like:
>
> ? (use-interface-root :tiger)
> ....
> and then something like
>
> ? (use-interface-dir :cocoa)
>
> I'm not sure what it would mean to use or to have used multiple
> "roots" in the same session.
>
> That seems like overkill.  The interfaces for OS release N are (usually,
> mostly) a superset of the interfaces for release N-1, so simply considering
> the most recent set of headers (the Tiger ones, at this point) to be
> canonical is certainly simpler and probably at least as useful.
>
> A (possible) advantage to the XCode-like scheme is that you'd be able
> to say
>
> ? (use-interface-root :panther)
>
> when developing something intended to run under Panther or Tiger, and
> attempts to use Tiger-specific functionality would (mostly) be caught
> at compile-time.  (That was kind of the justification for basing the
> 1.0 interfaces on Panther, as I recall.)  As you note, that prevents
> (easily) targeting Tiger, so that's also an imperfect solution.
>
> [If you don't care about much of this and just want to be able to
> use some Tiger-specific features in a Cocoa application, there's
> a set of Tiger Cocoa interfaces in:
>
> <ftp://clozure.com/pub/testing/tiger-cocoa-interfaces.tar.gz>
>
> ].
>
> On Tue, 13 Jun 2006, Phil wrote:
>
>> I've noticed a couple methods and related constants missing from the
>> Cocoa bridge that I wanted to pass the info along...
>>
>> NSDatePicker - setDatePickerStyle and it's constants
>> (NSTextFieldAndStepperDatePickerStyle and
>> NSClockAndCalendarDatePickerStyle from NSDatePickerCell.h)
>> NSTableColumn - setResizingMask and it's constants
>> (NSTableColumnNoResizing, NSTableColumnAutoresizingMask, and
>> NSTableColumnUserResizingMask from NSTableColumn.h)
>>
>> Thanks,
>> Phil
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>