[Openmcl-devel] Trying to use AddressBook

[Gary Byers]

AddressBook is likely something like WebKit (a set of Cocoa classes
that are large enough and domain-specific enough to be distributed as
their own framework.)

The good news is that there's a (very simple) example of using WebKit
in the OpenMCL 1.0 distribution, and the steps involved in using 
AddressBook shold be similar.  The bad news is that there's some
one-time setup involved and a little bit of startup work to be
done in any code that uses AddressBook (or WebKit, or ...) under
the Cocoa Bridge.

The one-time setup involves generating interfaces (.cdb files)
describing the classes and methods in the AddressBook headers,
so that it'd be possible to say something like:

(use-interface-dir :addressbook)

In the WebKit example, the analogous

(use-interface-dir :webkit)

is followed by a call to

(ccl::update-objc-method-info)

This has to do with how SEND works: some ObjC methods that use
the same message selector may have different argument argument
and/or result types, and the new interfaces may introduce this
kind of ambiguity for messages the bridge -thinks- it already
knows how to send.  This is a little obscure, but it's important,
and it may be idiomatic enough that there should possibly
be a (USE-INTERFACE-DIR-FOR-NEW-OBJC-INTERFACES :name) construct.

The startup work that code that uses AddressBook has to do at
runtime involves opening the framework's librar[y|ies] and
telling the bridge that there may be (probably are) lots of
new classes (and that it should make CLOS metainformation
for new classes that're described in the headers.)  The webkit
example opens the library (or libraries) associated with the
WebKit framework by creating an NSBundle and sending it a
'load message if it's non-null; it tells the bridge to (re-)
examine the classes known to the ObjC runtime by calling
CCL::MAP-OBJC-CLASSES.  This happens in the function CHECK-FOR-WEBKIT
(in "ccl:examples;webkit.lisp"); it's almost boilerplate (aside
from the fact that it has the path to the WebKit framework
hardwired into it.)  It wouldn't be unreasonable to have some standard
LOAD-COCOA-FRAMEWORK function that did all of this.

This is all a little different than it used to be (pre-1.0), because
the bridge now uses the interfaces to interpret what it finds by
introspection on the runtime.  The old approach - which was based
entirely on introspection - was (a) slow and (b) brittle, but it
was also (c) more flexible in some ways.  I think that the new
approach is better, but it does require using the interface
translator (FFIGEN).  For the last few years, that's been more
of a black art than it should be, mostly because FFIGEN had
suffered bitrot.  The shiny new version works pretty well and
should work on "modern" OS releases, so hopefully it's fair
to say that generating interfaces for something like AddressBook
is "a little awkward" rather than "downright painful."

If this makes sense so far, great, and if you want to pursue this
on your own please let the list know if you're successful or if
you encounter further problems.


On Sat, 22 Oct 2005, Ralph Richard Cook wrote:

> I'm trying to get to the Cocoa AddressBook system with OpenMCL. I don't think 
> that the AddressBook classes aren't pulled in with the COCOA stuff.
>
> WIth regular Cocoa it's done with
> ABAddressBook *book = [ABAddressBook sharedAddressBook];
> where sharedAddressBook is a class method.
>
> I'm trying
> (open-shared-library "/System/Library/Frameworks/ 
> AddressBook.framework/AddressBook")
>
> then various combinations of ccl::find-class and ccl::@class to no avail.
>
> Any help and examples would be appreciated.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>