Migrating scripting additions to Mac OS X
Migrating scripting additions to Mac OS X
- Subject: Migrating scripting additions to Mac OS X
- From: Jolly Roger <email@hidden>
- Date: Mon, 25 Jun 2001 12:41:35 -0500
On 6/25/2001 10:56 AM, "Hudson Barton" <email@hidden> wrote:
>
> I've been learning MacOS X since Public Beta was released (I'm reading
>
> "Learnig Cocoa" now). I think OS X is very exciting OS, but I wonder
>
> about value of AppleScript (AppleEvent) on MacOS X (besides current
>
> imperfect implementation). For now, I'll learn and search OS X. If
>
> I get the conviction that porting my osax into OS X is not
>
> meaningless, I'll do my best.
>
>
Can you explain this further.... why you think Applescript for OS X
>
might be meaningless. Of the 20 most popular scripting additions,
>
NONE have made the transition yet, to my knowledge. Perhaps other
>
developers feel as you do.
(I'm cross-posting this to the AppleScript-Implementors list because I think
it has relevance there. Please excuse my cross-post if you feel
differently.)
I'm an scripting addition developer; but I can only speak for myself here.
I don't see anything preventing scripting addition authors from updating
their scripting additions to run on Mac OS X. One of the easiest, fastest
ways to do so is to convert the scripting addition to into a carbonised
scriptable application.
From a programming standpoint, the main difference is that you have to
include an application skeleton (code for an event loop and optionally menus
and other interface elements, if it's not a faceless background app). This
is trivial. You can pick up application starter code from any number of
places on the web if you don't feel like writing your own.
From a user standpoint, the main difference is that you call a scripting
application using a tell block rather than "globally". This is a small
inconvenience in light of the many benefits you gain. Besides the inherent
side effect of being able to run in both Classic and Mac OS X, there are
plenty of other benefits to be gained by converting a scripting addition to
a scriptable application:
Since a scriptable application is not a standard scripting addition, it
does not share the global namespace with all other scripting additions. To
send commands to a scriptable application, you enclose the commands in a
tell block. Because of this, script writers do not have to worry about
terminology name conflicts with other scripting additions.
Since a scriptable application is an application, it can be loaded and
unloaded at-will. To unload a scriptable application, you simply send it a
quit event. In comparison, to unload standard scripting additions you
generally must remove them from the Scripting Additions folder and restart
the computer. Also, some scriptable applications such as "URL Access
Scripting" automatically quit themselves after a certain amount of idle
time.
In classic Mac OS, a scriptable application lives in its own memory space
rather than taking up space in the application heap of the application that
called it. The more memory left for other applications to do their jobs, the
better.
A scriptable application runs in its own application space. Therefore, in
the event that a scriptable application crashes, other applications should
not be affected. In comparison, if a scripting addition crashes, the
application that called the scripting addition usually crashes as well.
(These are some of the benefits off the top of my head. There may be more I
haven't thought of.)
It seem to me that the effort needed to convert a standard scripting
addition to a scriptable application is miniscule in comparison to the
benefits users gain.
I would think that most scripting addition developers would want to move in
this direction in the future. Comments?
JR