Re: The future for AppleScript
Re: The future for AppleScript
- Subject: Re: The future for AppleScript
- From: Mark Lilback <email@hidden>
- Date: Thu, 10 Feb 2005 15:51:09 -0600
At 12:01 PM -0800 2/10/2005, Paul Berkowitz wrote:
My understanding is that to "build Automator support directly", the app
would a) have to be Cocoa and b) make its APIs public, as , say Apple's
Address Book and iChat are, but not much else. Perhaps I've misunderstood
this part?
No. Pure Cocoa Automator actions have to call a C or Objective-C API.
99% of the time, that API will come from a Framework. If that
framework is embedded in the application (like the OmniFrameworks in
OmniGraffle, OmniWeb, etc.), then the Automator action can't link to
them because the framework has to be in a known path -- absolute, or
relative to the executing application (Automator). So unless
developers are going to start dropping their frameworks in
/Library/Frameworks and using installers, they aren't going to be
writing pure Cocoa actions.
Apple can get away with it because their stuff is all in known locations.
I have a feeling that most actions will use both Cocoa and
AppleScript. I found that to be the easiest way, since the two can
talk with each other very easily.
So the question is whether Cocoa Automator actions can actually be written
for an app that does not expose its APIs. I don't understand how they could
be. Even AppleScript Actions will be able to access system-level features
via Cocoa commands, and enhance their capabilities that way as needed. But
we're all talking here about application control.
Any application or framework that is written in Objective-C can have
its APIs exposed by using class-dump, which generates header files
from the binary. Now those header files aren't nearly as easy to use
as publicly provided headers, but they certainly can be used. I've
done this a number of times so I can add features to my products.
For example, if a framework is being exposed to AppleScript Studio,
there is no public way to add an element/property to the core
application class to allow a script referencing those
elements/properties to compile.
I hacked a way around this using class-dump and a number of other
tools. Now that hack might not work with Tiger, since Apple is free
to change how non-public APIs work. So I'll have to come up with
another hack for Tiger. But I'm willing to accept that, as there was
no other way I could have offered that feature.
--
__________________________________________________________________________
"The fetters imposed on liberty at home have ever
Mark J. Lilback been forged out of the weapons provided for
<email@hidden> defence against real, pretended, or imaginary
http://www.lilback.com/ dangers from abroad." -- James Madison
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden