[Openmcl-devel] Deploying Cocoa Apps
Gary Byers
gb at clozure.com
Thu Mar 2 02:30:19 PST 2006
On Thu, 2 Mar 2006, Francesco Pierfederici wrote:
>
> Hi,
>
> Thank you for the quick reply.
>
>> There are some tradeoffs: using Cocoa add-on libraries is possible,
>> but harder than it needs to be. There's an example that uses the
>> WebKit framework that's distributed with 1.0 that seems to work,
>> but people who've tried using other frameworks have found that it's
>> necessary to jump through more hoops than were necessary to jump
>> through when you could just say "new libraries have been loaded,
>> go learn about their classes and methods."
>
> Is there some documentation on how to load add-on Cocoa libraries? I will
> also look at the examples in the distribution, of course.
The WebKit example seemed to work out of the box.
A little while after 1.0 was released, someone asked how they'd go
about using another add-on (AddressBook ?). I said something like
"just do what WebKit does"; a little while later, they replied saying
that they'd done what the WebKit example does (run the header files
through the interface translator and tell the Cocoa Bridge to use
those translated interfaces while opening the appropriate framework
bundles) and things weren't working (no CLOS metainformation existed
for the AddressBook classes.) We went through a few iterations of
"hmm, try this" and "that half worked, but this still doesn't work"
before we discovered the right incantations.
I was left with the impression that the right thing to do was to
provide some public function or method to tell the bridge "use this
ObjC add-on library, described by these interfaces, and build all
of the CLOS and SEND support for it." What we did to get AddressBook
involved calling a handful of random internal functions (some of which
may not do much error/sanity checking) in the right order.
(I don't remember the details, but I think that that I also convinced
myself that the WebKit example worked by blind luck/accident.))
So, the right thing(s) to do would seemingly be:
1) package the "handful of random internal function calls" into
something sane and usable
2) document the result of step 1
3) try a few more Cocoa add-on libraries, repeating steps 1 and 2
as necessary until we're confident that the issues are well-understood
and the means of dealing with them are reasonably general.
I've been busy with other things, and have not put much time into anything
Cocoa-related since before the 1.0 release. I will try to make that time
and will try to do so soon, but can't predict exactly when; if I was
thinking about it and the issues were fresher in my mind, I don't think
that it'd take too long to try to resolve them, but at the moment I'm
not and it's a little hard to shift gears.
[It's also possible that fixing this would take less time than explaining
why I don't have time to fix it. Maybe.]
>
> Thanks!
> fra
>
>
>
>
>
More information about the Openmcl-devel
mailing list