Re: iWork Pages
Re: iWork Pages
- Subject: Re: iWork Pages
- From: has <email@hidden>
- Date: Wed, 26 Jan 2005 16:58:44 +0000
John C. Welch wrote:
>From the public API for automator, there's only two ways to do Automator
modules [that control another] app.
1) the application puts in a decent dictionary, and the modules are then
written in studio.
Or any other language that can speak Apple events and hook into
Automator's ObjC API. Of these, ObjC, Perl and Python are the most
obvious candidates as both already provide extensive bindings to both
the Apple Event Manager and Cocoa APIs. I think Ruby and a few others
have Cocoa bindings too, although their application scripting support
is much weaker and probably not much fun for controlling apps this
way.
Incidentally, if Apple would make Studio a bit more accomodating
towards other OSA languages then you could one day be writing
Studio-based Actions using TclOSA, PerlOSA, PythonOSA, UserTalk, etc.
as well as AppleScript. [1] I've not seen Tiger yet, but I'd guess
that the Studio APIs for developing Actions are easier to get started
with than the more powerful, complex Cocoa ones. So I could see this
approach appealing to folks who know - say - UserTalk, but currently
don't have the time, knowledge and/or need to go the more complex
Cocoa route.
2) You use Cocoa frameworks for everything, expose and document all your
uses of said frameworks, and force all the modules to be Cocoa - only.
This of course, is much more complex for what Automator is designed
to do, and it
severely limits the number of people who are able to write modules.
The total number of Action developers is likely to be limited anyway.
However, you don't really need all that many Action developers to
service the needs of a very large userbase very nicely. The real
disadvantage is that it will be much, much harder for those Automator
users who are not already programmers to start developing their own
custom Actions to automate non Apple event--savvy apps if/when they
outgrow the first- and third-party ones. Because Cocoa programming is
significanty harder to learn than AE-based application scripting, the
presence or lack of an AE interface in an application could very well
be the difference between these folks getting a foot in the door and
being stuck permanently on the doorstep.
This is already the case for AppleScripters, of course, but once
Automator appears it's very likely to suck in a whole new audience of
nascent Mac scripters, many of whom will be even less familiar or
comfortable with programming than ASers are. So providing lots of
extremely gentle, easy-to-enter routes into this whole new world of
under-the-hood Mac automation is going to become even more important
than ever if these folks aren't to be eternally, negligently,
disgracefully locked into "end-luser ghetto-land".
Let's hope the application developers are listening.
has
[1] Philip Aker is doing some very good work bringing OSA support to
a range of scripting languages:
<http://homepage.mac.com/philip_aker/osa/osa.html>. And UserTalk,
whose application scripting support predates even AppleScript's, may
be undergoing something of a renaissance now that it's been
open-sourced.
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
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