Re: Nice Automator article on O'Reilly
Re: Nice Automator article on O'Reilly
- Subject: Re: Nice Automator article on O'Reilly
- From: Martin Orpen <email@hidden>
- Date: Thu, 05 May 2005 00:56:26 +0100
on 4/5/05 23:43, Christopher Nebel at email@hidden wrote:
> On May 4, 2005, at 12:30 PM, Martin Orpen wrote:
>
>> Don't say I didn't warn you in the thread "The future for
>> AppleScript".
>
> I'd originally written this for the "The future for AppleScript"
> thread almost three months ago, but never posted it because it would
> probably have devolved into me saying "I can't tell you that until
> Tiger ships." Obviously, that's no longer an issue, and Martin still
> seems to be stuck on the same point, so here we are...
Appreciate the difficulty with discussing this stuff prior to Tiger's
release. And glad to hear that I've got *misconceptions* because I *like*
AppleScript.
> On Feb 10, 2005, at 3:57 PM, Martin Orpen wrote:
>
>> on 10/2/05 8:24 pm, has at email@hidden wrote:
>>
>>> Martin Orpen wrote:
>>>
>>>>> And what do you think the simplest way for an ISV to provide
>>>>> hooks for
>>>>> Automator is going to be?
>>>>
>>>> Well, if you've got a choice of two methods and you've written
>>>> the app in
>>>> whatever-C then I doubt that you're going to bother inserting an
>>>> AppleScript
>>>> Automator Action when you can see Cocoa Automator Action sitting
>>>> below it.
>>>
>>> You're confusing 'AppleScript' for 'Apple events'.
>>
>> I'm not confusing anything - just repeating the two options
>> available when
>> you use the Tiger version of Xcode - look at the Automator page on the
>> developer site to see for yourself.
>
> You know, there are a lot of misunderstandings running around here.
> [1] I'm guessing Martin is referring to this bit from <http://
> developer.apple.com/macosx/tiger/automator.html>:
>> There are three general types of Automator Actions that you can
>> create:
>>
>> - Actions that control an application to get something done. If the
>> application is scriptable, AppleScript can be used for these types
>> of Actions. Objective-C is a good choice if the application has a
>> public API, such as Address Book and iChat.
>>
>> - Actions that use system frameworks or other system resources to
>> get something done. This is typically a job for Objective-C.
>>
>> - Actions that perform a "bridge" function, such as prompting the
>> user for input, writing output to disk, or converting data from one
>> type to another. These types of Actions can be written in either
>> AppleScript or Objective-C.
>
> So, misconception number one: AppleScript actions imply all
> AppleScript all the way down, Objective-C/Cocoa actions imply
> Objective-C/Cocoa all the way down. As they say in my country,
> "no." There are indeed two basic interfaces to actions: AppleScript
> and Objective-C. That is, your action is either going to have an "on
> run" handler (AppleScript) or a "-[MyAction
> runWithInput:fromAction:error:]" (Objective-C). This does not
> dictate (much) what you do once you're inside that handler. If you
> start in AppleScript, you could do everything else in a shell script;
> if you start in Objective-C, you could start calling C stdlib or
> shell calls or even start throwing Apple events around -- whatever
> gets the job done. (Obviously, some things are easier in some
> languages than others, hence the "much".)
Let's not get ahead of ourselves here.
Michelle has rightly pointed out that the information posted by Matt Neuberg
is certainly *AppleScript-Like* - but it isn't really AppleScript is it?
There's AppleScript in it, but it's wrapped in something pretty
foreign-looking to people who only use Script Editor.
So, it would be more honest to call it an Xcode project with some
AppleScript thrown in...
> Moving on to misconception number two: it's easier for application
> writers to provide an Objective-C API than it is to make their
> application scriptable, especially if they're already written in
> Cocoa. Again, no. As an application vendor who wants to Play NiceĀ
> with Automator, your task is to expose a programmatic interface to
> your application so that the actions can get at the interesting bits.
> [2, 3] (Revisiting misconception #1 for a moment, this "programmatic
> interface" just has to be callable from at least one of AppleScript
> or Objective-C -- it does not have to actually *be* AppleScript or
> Objective-C. Python, for instance, would be an unusual but workable
> choice.)
>
> So, given full freedom, what do you (the application writer) do?
> Well, being lazy, as all good programmers are [4], you want to do as
> little as possible. For any reasonably well-designed Cocoa
> application, adding scriptability is actually the lowest-cost
> solution. Refactoring stuff into a callable framework is usually
> hard. Added bonus: if you make your application scriptable, then
> other people will write actions for you!
>
> Forget any notion that an Objective-C action implies talking to an
> Objective-C (Cocoa) application -- it doesn't. Forget any notion that
> an Objective-C/Cocoa application will have an easier time exposing a
> pure Objective-C interface -- it won't. (Well, unless it has
> already. Omni did. On the other hand, their stuff is all
> scriptable, too.)
You'll have to forgive me for slowing you down again as my point was a
little more complicated than that.
AppleScript is presented to us as a really great way of communicating
between applications. It flounders after launch because most Mac users don't
get it. But, some of us - particularly pre-press people like myself - get
into it and it manages to survive a couple of pre-OS X OSs.
OS X gives AS a speed bump and some extra features and everybody is
generally happy that their is life in the old dog yet. But, there are some
confusing things about OS X:
AppleScript is better, but the Apple apps are just about the poorest to
script. And, at the same time, those very same apps are exposing useful
features to people who are able to communicate with them using obj-c
methods.
So, it looks to me as if AppleScript is floundering again :-( - and somebody
at Apple has come up with a brilliant idea of re-launching the humble
AppleEvent and a simple way of using it in the form of Automator.
I think that this is as good an idea as AS was, but I personally don't find
it half as appealing.
An AppleScript dictionary is so much more *interesting* to look at than a
fixed Automator Action :-(
> Oh yes, and the third misconception -- more of a bias, really:
> Automator is inherently useless to someone who already knows how to
> write scripts. Well, that depends on how much you enjoy writing
> scripts by hand. For instance, I'm perfectly capable of writing a
> script that will recursively walk a folder tree lower-casing all the
> file names. But you know what? I'd rather not bother, especially
> when, in under a minute, I can build an Automator workflow that does
> the same thing. Added bonus: it's so bloody easy that I don't even
> have to bother filing it for the next time I need it.
That wasn't my point (although I do find writing scripts by hand enjoyable),
my point was that vanilla AS looked to be heading for a renaissance with OS
X only to fizz and then die because it ends up caught between the anodyne
Automator and power of whatever other language gives you more direct access
to a specific app or the OS.
IMHO, AS meant linking apps together in ways that people didn't envisage
when they wrote the dictionary. Automator *may* mean linking apps together
in ways that other people have already placed limitations on. It may not,
but it just looks a little dull (to me).
Regards
--
Martin Orpen
_______________________________________________
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