Re: History of Scripting Terms (was Re: Attachability)
Re: History of Scripting Terms (was Re: Attachability)
- Subject: Re: History of Scripting Terms (was Re: Attachability)
- From: Cal <email@hidden>
- Date: Wed, 7 Feb 2001 22:20:31 -0500
Peter Fine <email@hidden> wrote:
Leonard Rosenthol at email@hidden wrote:
As one of the people who helped defined the original terms for
"levels" of scripting, I guess I should put my two cents in.
For anyone keeping historical records, feel free to note that the
first formal discussions about defining types/level of scriptability
took place at a pre-WWDC "coding kitchen" at Pajaro Dunes (CA) in May
of 1992. Among those present (that I remember) were myself
(Aladdin), Don Brown (CE Software), xxx (Word Perfect), Brandon
McCarthy (Claris/FileMaker), xxx (Shana) and some key Apple people
including Mark Thomas (Evangelist) and Don Dehnman ("Father of
> AppleScript").
And I was seeded with AppleScript the following week, so I didn't get
to participate in that.
> At the time, we defined four levels of "scriptability" that any given
software product could achieve.
* Scriptable - supported any Apple events and included an 'aete'.
Since this was BEFORE the Apple Event Object Model (AEOM) existed, we
weren't concerned with "quality" of implementation - just that they
had something!
* Recordable - allowed the user to record the events as they took
place so they could be played back.
* Attachable - provided a way for the user to run scripts from "user
interface elements" in the application. At the time, we were
thinking more along the lines of buttons/fields in a database or form
processor, cells in a spreadsheet or folders in the Finder. The idea
of attaching to menus and "Script" menus came later - most likely as
a response to Jens' Script Menu and my OSA Menu.
* Tickerability - allowed the user to override, replace or add
functionality to an application through scripting. This is what
products like Style and Script Debugger do by allowing users to
> install handlers that can modify standard application behavior.
Tickerability: n. 1. The capability of obtaining stock quotes. 2.
The generation of blood-sucking insect that normally drop down from
the trees. 3. The placing of guide marks along one or both axes of a
chart or graph.
Tinkerable: n. 1. The act of relieving onesself while scripting,
particularly during childhood (often accompanying the surprise upon
opening the dictionaries of certain non-object model applications).
2. Designing a software program using brightly-colored wooden shafts
and discs.
> Whether these terms are still valid and/or accurate, and should still
be used as is or with modification is a discussion that comes up
every few months. I simply offer the above as a historical
perspective and a starting point for those having the discussion
today with respect to what we "pioneers" believed almost 10 years ago
(wow!).
Attachable has been used rather consistently in Apple publications to mean
something broader than Leonard sets forth. Tinkerable, thank God, has never
been used by Apple and seems to have been know only to the Innermost of the
Innermost.
For current use, the choice seems to be between using "attachable" in a
broad sense or splitting the subject matter into "attach" = "has a Scripts
menu" and "embeddable" = "everything else".
It's always been true that many more applications support a Scripts
menu than any other use of the earlier term "attachable". So in
order to further help users/scripters determine the capabilities of
an application, and after discussions with the AppleScript team, I
further refined the original terms, making the clear distinction
between the broader case of associating scripts with objects and the
specific case of doing a Scripts menu (the easiest-to-implement and
most common case). In my develop column, I clearly defined the
terms. (Be aware that develop articles went through stringent,
sometimes lengthy, technical review by multiple Apple engineers.)
Apple again gave the nod to this distinction when the Scriptability
Scorecard was done. (It was my hope that two things would happen:
1) Because it was really easy, developers all over the universe would
implement a Scripts menu, regardless of whether their application was
scriptable, and 2) Developers would begin to look at associating
scripts with user interface elements in their applications.)
There are significant differences, not only in the implementation
details and effort level required, but also in the user experience.
Scripts menus basically look and operate the same, regardless of the
application, while the user interfaces of the provisions for embedded
scripts vary widely between Smile and FaceSpan. So calling something
"attachable" can mean a consistent user experience that's easy to
implement...hence, "attach" = "has a Scripts menu" and "embeddable" =
"everything else".
Also in the area of helping user/scripters evaluate the usefulness of
the scripting in applications, I forked off object model support from
scriptability. Supporting the object model is the single most
contributor to a consistent feel of the AppleScript language across
applications of different types (wow...deja vu...I said this in
Develop 21, in almost the same words, six years ago!)
Richard 23 <email@hidden> wrote:
Calling an application attachable merely because it adds a scripts menu
seems to me like calling an application scriptable because it implements
"do script" or "do menu". I thought attachable meant that one could
attach
scripts to application objects <-- (plural!) not just to the scripts menu.
Actually, the scripts are being associated with menu items, so it is plural.
And while you might consider that "do script"/"do menu" and attaching
scripts to menu items to both be lightweight implementations, there's
an important distinction. Do Script and Do Menu allow a scripter to
control an application using things other than AppleScript/OSA
(internal application-specific languages and physical user
interface), while a Scripts menu is purely an AppleScript/OSA thing
all the way. Make of it what you will.
Bill Briggs <email@hidden> wrote:
I agree with you Bill. In fact, Cal is contradicting himself here.
Page 8 of his own Scripter manual reads thus:
"Attachable: An attachable application supports the attaching or
embedding of a script to an object within the application. An
attachable application can associate a script with a button or with a
field in a form, for example. When you click the button or tab out of
the field, the script will run. In some attachable applications, a
script can be associated or embedded with an object or its data, such
as documents which hold different scripts."
Yes. This is because the original Scripter manual was written in
1994, using the earlier definitions. The descriptions in our manual
were intended to provide overview material about AppleScript; the
Scripter manual is not an Apple-approved publication, and should not
be taken as the gospel on this particular subject. This would be a
good thing for us to revise.
Phi Sanders <email@hidden> wrote:
What great development is it to have a Script menu?
I think it's very little conceptually... although few enough apps have them.
Many scripters here take advantage of it, even though it's easy to implement.
So, (in my mind at least) an app with a script menu is simply "scriptable",
and I would reserve "attachable" for apps whose objects and functions can
be "extended" via OSA Scripts :
Unfortunately, what's in your mind isn't accurate. Applications can
(and do) support a Scripts menu without being scriptable. It's 10 or
20 times easier to implement a Scripts menu to an application than it
is to make one scriptable.
And I hope no one ever has to say "tinkerable" again...
Amen, brother.
Cal