Talk:AppleScript

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Programming language reference[edit]

Even as a confirmed Macophile, I think it's a bit much to describe AppleScript as a "programming language," especially since the same description isn't applied here to JavaScript or Perl. - Hephaestos 04:45 Mar 1, 2003 (UTC)

I've moved it back to where it belongs. Some time ago, someone decided for mysterious reasons to rename all the articles about programming languages in the form "X programming language", even though the only sensible reason to use such names was as a disambiguator for things like "C" or "Pascal" whose names are not unambiguous by themselves. As you come across any that have not yet been put back, please rename them or, if there are problems with split page histories, give a shout out at the pump. --Brion 04:49 Mar 1, 2003 (UTC)
Um, the above discussion seems to imply that the form 'X programming language' was corrected in March of 2003, but in fact it is now August of 2004, and the article's name is 'AppleScript programming language.' I would like to correct this myself to simply 'AppleScript,' but I don't know how, (I understand about the 'move' tab, but I'm uncertain because of all the warnings about links changing). AdmN 16:37, 19 Aug 2004 (UTC)
I think I am now in favor of "AppleScript programming language", based on discussions at Wikipedia talk:Naming conventions (languages). AdmN 23:03, 21 Aug 2004 (UTC)

Editors and IDEs[edit]

Just typing out loud: I think we need a section on script editors and IDEs, with seperate articles as well:

And while we're at it, people and places:

I recently created Late Night Software, check one off the list. :) func(talk) 21:48, 21 May 2005 (UTC)[reply]

Can we really call the script menu, and the Apple script utility "Development tools"? There should be at least some requirement that you have to be able to, well, develop with a tool for it to be a development tool. The Script Menu is a tool for running, not creating scripts, and the AppleScript utility is there to control some user-level interactions with scripts. Neither let you create scripts. Perhaps an "Other tools" section?Johncwelch (talk) 22:34, 27 December 2008 (UTC)[reply]

There is now a stub: Script Editor. I guess a disambig was not felt nessesary. —Preceding unsigned comment added by 70.20.209.146 (talk • contribs) 07:10, 14 February 2006

Refined the Automator section a bit to include more correct verbage, (actions), and OS Versions for Automator (10.4 and later).Johncwelch (talk) 22:42, 27 December 2008 (UTC)[reply]

Added in sections for Script Debugger, FaceSpan, and Smile. Johncwelch (talk) 23:01, 27 December 2008 (UTC)[reply]

Possible confusions[edit]

  1. In Mac OS X AppleScript is simpler for developers to implement, particularly for those applications being developed in Cocoa.

    Simpler than what? Cocoa? I'm confused. If it's simpler than Cocoa, then why then does the rest of the paragraph address how versatile and good Cocoa is? (I'm going to read about what "Cocoa" is in a moment, but I know it is some kind of Mac-based Obj-C variant.)

  2. Unlike the Mac OS where events are handled by the applications, under Cocoa, events are decoded into a "high level" command by the NSApplication object, and the messages dispatched directly to the correct object. That is, all Cocoa applications are "factored" by default; the developer doesn't write any of the event handling code (normally) and writes only the "work methods" that those events will call. Another major advantage is that Cocoa objects are presented to the outside world (other applications and even machines) in a standardized format that anyone can examine directly.

    Shouldn't this be in the wiki article on Cocoa? Does writting an application in Cocoa make it easier to then write a script in AppleScript that "hooks into" that application? That is not quite clear to me.

  3. Under Cocoa AppleScript is much "thinner"; the script engine decodes the script, translates object names from human-readable to their internal format, and then calls those methods on the target application directly.

    Is "Cocoa AppleScript" the name of some kind of hybrid language, or is there a comma missing? And is this saying that when I use AppleScript to address applications written in Cocoa (as opposed to... Java or C++ ?) then my script will run faster? What does "thinner" mean?

I'm just starting out, and I'm sure when I hunt deeper I will find the answers to all of these questions, but it might be confusing to other neophytes. --128.237.234.9 15:37, 25 May 2006 (UTC)[reply]

  1. Presumably means simpler than in OS9. It's still misleading though. What it should really say is that scripting support is easier to implement in Cocoa-based applications than Carbon/Classic ones: a lot of the code for processing Apple events is built into the AppKit framework, so developers have to provide less code themselves.
  2. a) Quite possibly. b) No, the only advantage to users is that Cocoa-based apps tend to be a bit more consistent in how they behave compared to Carbon apps since more of the underlying mechanisms are the same from app to app.
  3. Missing comma. And it's wrongly confusing AppleScript, which is a client language, with Cocoa Scripting, which is the part of AppKit that provides its scripting support. The way AppleScript works hasn't changed since OS9, and it certainly doesn't "call methods on the target application directly"; it sends Apple events to the target application just as before. What's new in OS X is the way that AEs are interpreted in Cocoa apps. Carbon developers have to write quite a bit of glue code to connect their Apple event handlers to their application's Model layer. Thanks to ObjC's highly dynamic nature, Cocoa Scripting can use advanced features like key-value coding to look up a lot of stuff automatically; all the developer has to do is annotate the application's scripting definition (dictionary) with the names of the accessor methods/attributes to use, no coding required. I assume that's what the original author was getting confused about.
I wouldn't feel too bad about confusing folk: a lot of the article is very ropey and some parts are just outright wrong, so addressing the problems you've found so far can only improve it even if more work is needed later. It would make sense to eventually move most/all of the discussion on how application scripting support is actually implemented to Apple event, Apple Event Object Model, Cocoa Scripting and/or Cocoa articles, and focus this article on just the AppleScript language and the general principles involved in application scripting. That'd help eliminate at least some of the current confusion by reducing the number of different topics being discussed here.--Hhas 15:57, 14 July 2006 (UTC)[reply]

Links[edit]

Three of the links at the bottom (http://macscripter.net/, http://scriptbuilders.net/, http://bbs.applescript.net/) are all part of the same site grouping, so to speak. They should probably be consolidated somehow. 71.240.242.39 14:44, 15 June 2006 (UTC)[reply]

"Arguable that"[edit]

"It is arguable that the main reason that the Mac remained a powerhouse in the publishing market after Quark (and other applications) were ported to Microsoft Windows, was that Mac users could automate complex workflows." How about getting rid of the weasel words? ("It is arguable that...") --Aughtandzero 02:24, 27 June 2006 (UTC)[reply]

Article Problems[edit]

This article contains multiple errors, omissions, misconceptions, etc. It'd take some time to go through them all, so for now here's one example of the sort of fundamental inaccuracy that needs to be dealt with:

"Note the similarities between the AEOM model and the considerably more recent DOM system used in XML. Both decompose a document into a hierarchy of objects, and offer the programmer a standardized iterative method to access the contents. Differences between the systems lie primarily in the user-level syntax"

This is both misleading and wrong. There are major differences between AEOM and DOM. AEOM operates at a much higher level of abstraction: DOM is a simple object-oriented API; AEOM is a query-driven View-Controller layer that sits above an application's object-oriented Model layer, rather like how XPath sits atop DOM. "User-level syntax" is irrelevant, since the Apple Event Manager is a programmatic API; whatever user-level syntax AppleScript, Mac::Glue, etc. want to spread on top of that is entirely up to them. (Current high-level bridges all happen to use an OO-like syntax, which is probably one of the reasons a lot of observers mistakenly think AEOM is 'just another DOM'.)

The following comparative example from the article reinforces this basic misunderstanding of how the AEOM works:

The concept of an object hierarchy can also be expressed using nested prepositional phrases: 

  pixel 7 of row 3 of TIFF image "my bitmap"

which in another programming language might be expressed as sequential function calls: 

  getTIFF("my bitmap").getRow(3).getPixel(7);

Object specifiers (the 'pixel 7', 'row 3', etc.) are not comparable to accessor methods. On the client side, what you're doing is constructing a single, first-class query object that will eventually be packed into an Apple event and sent to the application to interpret, not invoking a bunch of accessor methods as the second code segment implies. AppleScript may use an OO-like syntax for constructing these queries, but it's completely wrong (if a very common mistake) to assume, based on appearance, that it must also follow OO rules and behaviour.

In another language, the above 'reference' (i.e. query) would be expressed, sans syntactic sugar, as something like: 

q = Query().elementByName('TIFF image', 'my bitmap').elementByIndex('row', 3).elementByIndex('pixel', 7)
print q 
# <AEBridge::Query 0x16c71b4>

To actually get the referenced object/value, you'd then need to construct and send a 'get' event containing that query as its direct parameter: 

q = Query().elementByName('TIFF image', 'my bitmap').elementByIndex('row', 3).elementByIndex('pixel', 7)
result = Application('My Graphics App').send('get', q)

For usability's sake, properly designed high-level bridges like to hide a lot of this pedantry beneath a more concise, easier-to-read syntax, e.g.: 

q = app('My Graphics App').TIFF_images['my bitmap'].rows[3].elements[7]
result = q.get()

but underneath this surface everything is being translated to queries as before. It's a bit like how object-relational mappers provide an OO-like interface to relational databases.

Anyone planning to work on this article should read the following paper by two of the original Apple engineers first: The Open Scripting Architecture: Automating, Integrating, and Customizing Applications (Cook & Harris, 1993; PDF). While it predates newer additions like Cocoa Scripting, it's the best explanation the underlying concepts and principles, as well as the original technologies involved, that I'm aware of. --Hhas 15:57, 14 July 2006 (UTC)[reply]

External links[edit]

I've removed a wad of links to resources, implementations, tutorials, community sites etc. which didn't belong in here. This isn't meant to be a portal or starter guide to using the language. External links should be kept to a minimum of directly relevant encyclopedic resources. Chris Cunningham (not at work) - talk 11:17, 23 July 2008 (UTC)[reply]

Those links definitely belong there. This page is very often the first stop for people interested in learning AppleScript. If anything the "Official AppleScript Page" on Apple's website does not belong here, because that page has not been consistently available and the information and links on that page are not consistently updated.
That "wad of links" has been maintained and updated by several contributors over a period of years. —Preceding unsigned comment added by 144.142.21.44 (talk) 20:42, 23 July 2008 (UTC)[reply]
We're not here for "people interested in learning Applescript". Wikipedia is meant to describe subject matter, not teach content. And see WP:EFFORT for the counter-argument to "these have been maintained for years" - right now, they're not being "maintained" so much as reverted back in by a single editor. I'll leave them for a couple of days to see if anyone can come up with a valid reason why they should be kept, after which they'll be removed again as violations of WP:EL. Chris Cunningham (not at work) - talk 12:22, 24 July 2008 (UTC)[reply]
OK, I'll wait a few days too, see if anyone else jumps in, then I'll go back and check each link, remove the ones that don't meet the guidelines. The only other time I have reverted was when the page was clearly vandalized. All edits have been thoughtfully made by someone very familiar with the subject matter.

AppleScript Studio link[edit]

As far as I can tell, the "AppleScript Studio" link doesn't go anywhere. It would be nice if there really were a section (or better yet, a page) on this environment, but I'm not qualified to write it. —Preceding unsigned comment added by 71.243.10.93 (talk) 19:27, 5 December 2008 (UTC)[reply]

I removed the link. Maybe it linked to something in the past that got trimmed or moved around. At the moment I don't see anything to link to. Fletcher (talk) 20:01, 5 December 2008 (UTC)[reply]

There really isn't an "AppleScript Studio" to begin with. It's always been a marketing name for Xcode's ability to create apps/scripts with AppleScript, so any links should just go to Xcode. Johncwelch (talk) 16:46, 29 December 2008 (UTC)[reply]

Is Apple dropping support for Applescript Studio? In Xcode 3.2.1, the dictionary is no longer available in the file menu. —Preceding unsigned comment added by 206.109.195.126 (talk) 07:00, 8 June 2009 (UTC)[reply]

Aliases[edit]

    • alias - a reference to a file system object (file or folder). The alias will maintain its link to the object if the object is moved or renamed.

Removed this sentence for several reasons: "The object must exist in the file system, or the script will throw an error."

First, before Snow Leopard, if the alias file did not exist when the script was compiled, the compiler would display an error message.

In SL, that is no longer the case.

alias "Foo:"

compiles.

At runtime, if the object does not exist in the file system, an apple Event error would be generated. But any apple Event error can be trapped by a script so the script does not "throw an error".

try get alias "Foo:" end try

"Throw an error" is very imprecise term. It suggests to me that it would halt script operation, but it simply generates an Apple Event error that can be easily resolved without interrupting the operation. —Preceding unsigned comment added by 144.142.12.110 (talk) 01:32, 8 September 2010 (UTC)[reply]

The operative point here is that the file has to exist for an alias to work. do you disagree with that? and what language would would you suggest instead of 'throw an error', which is pretty standard computer programmer terminology, mind you. --Ludwigs2 01:27, 13 October 2010 (UTC)[reply]

No, I don't agree with that. The alias class can be used to test if a file exists and that "works"

In the past the alias class required the item to exist at the time the script was compiled, but that is no longer the case. Because of that, when I read "throw an error" I thought of a compiler error, as opposed to a runtime error, that could be trapped in a try block. That context makes the term imprecise.

If a complier error is what is meant here, then that no longer applies. If a runtime error is what is meant, then why single out the alias class for this comment? —Preceding unsigned comment added by 144.142.12.110 (talk) 01:45, 13 October 2010 (UTC)[reply]

Please remember to sign your posts with four tildes - you're giving SineBot a migraine.
The purpose of the alias class is to point to existing file system elements - it says so in the AppleScript documentation. The alias class was intended to leverage the ability of alias files to maintain a connection with their target even as the target is moved around in the file system; it makes no sense conceptually for an alias file to point to a non-existent file. The fact that Apple has fixed things so that it throws a runtime error rather than a compile-time error is nice, but doesn't change the fact that it throws an error. The fact that you can use it as a file system test is also nice, but Apple has the 'exists' verb in the Finder and System Events that tests for file system objects without throwing errors. we should be documenting the intentions of the language, not the hacks that work, if you follow me... --Ludwigs2 03:21, 13 October 2010 (UTC)[reply]

There are many ways to generate an apple event error in appleScript. There is no reason to single out this behavior of alias as if it were a weakness or a flaw. If this were a tutorial then a more indepth description would be appropriate. But this is simply an overview of the language and technology.

Yes the finder has an exists command, but this discussion is not delving into application scripting. Also using alias to test is more reliable, faster and uses less overhead than using the finder command.144.142.12.110 (talk) 18:57, 14 October 2010 (UTC)[reply]

Fair enough. or at least it's not a big enough issue to argue over. we'll leave it as you like it. --Ludwigs2 19:16, 14 October 2010 (UTC)[reply]

gone baby gone[edit]

I've been looking for the Apple scripts for folder actions and, under 10.8, they're all gone, or they are deeply buried. This is a total PO because I used to use a couple of them all the time as folder and file organizational tools. And there are no clues in Apple's documentation for Lion as to where the hell they've gone. Why get rid of a couple hundred KB of program when all machines measure their capacity in Gigs? Smooth move Apple, and (of course, the Apple plan, always) no warning.

Here's the point: this article needs to be rewritten to reflect the loss of those pre-written scripts that were so useful.Theonemacduff (talk) 02:06, 19 October 2012 (UTC)[reply]

AppleScript Wikibook[edit]

Should some of this content be migrated to or duplicated in the AppleScript Wikibook? Poetcsw (talk) 20:33, 22 April 2013 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on AppleScript. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:56, 16 October 2016 (UTC)[reply]

It worked, but saying what the MacRuby roadmap said back in 2009 isn't very interesting any more; they don't say anything about OSA now, so perhaps those plans were dropped and are no longer of any interest. Guy Harris (talk) 18:10, 16 October 2016 (UTC)[reply]

Inter application scripting language[edit]

One thing this page is missing is the entire point of the AppleScript language and technology. The purpose of appleScript is to provide one scripting language that can control multiple applications from a wide range of developers. As of now the page mentions Quark, Microsoft and Finder (With BBEdit as a link).

I understand why the list of scriptable applications was removed, but I believe it's appropriate to include such a comprehensive list.

AppleScript is nothing without scriptable applications. CarbShark (talk) 17:49, 4 October 2022 (UTC)[reply]

One thing this page is missing is the entire point of the AppleScript language and technology. No, it's not missing. First sentence of the article: "AppleScript is a scripting language created by Apple Inc. that facilitates automated control over scriptable Mac applications." First sentence of the overview section: "AppleScript is primarily a scripting language developed by Apple to do inter-application communication (IAC) using Apple events." And the word "primarily" in that statement looks right to me: it's not true that AppleScript is nothing without scriptable applications, since you can do other things with AppleScript, but for many purposes other languages are better.
This article does not need a comprehensive list of scriptable applications now, no more than this article needed such a list in its previous 20 years of existence. Wikipedia is not a directory of software applications. Biogeographist (talk) 21:12, 4 October 2022 (UTC)[reply]
A list of scriptable applications is not a directory.
The reason appleScript exists is for interapplication communication and scripting, and just one or two mentions with no detail is not sufficient.
There is very little useful things that can be done with appleScript without scripting applications (including Finder and system utilities) and there is nothing useful it can do without scripting applications that numerous programming and scripting languages can't do better. 2600:1700:4DB0:AAC0:D0D2:9A39:2AD7:938 (talk) 18:28, 5 October 2022 (UTC)[reply]
A list of scriptable applications is not a directory. In Wikipedia's definition, a directory is a list—an inappropriate kind of list. One use that I make of AppleScript all the time is to create droplets that run a shell script using whatever files are dropped onto them. That doesn't involve scriptable applications. But anyway the importance of scriptable applications to AppleScript in general doesn't justify a huge directory of scriptable applications in this article, no more than the importance of applications to a general-purpose personal computer operating system justifies a huge directory of applications specific to that operating system in the article about that operating system: there is no comprehensive list of applications in the article on macOS. It's the same here. Wikipedia is not a directory of software applications.
If you want to do something useful about scriptable applications on Wikipedia, why don't you create Category:macOS scriptable applications and put into it all the Wikipedia articles on scriptable applications. Then a link to that category can be put in this article. That would be a better use of your enthusiasm for scriptable applications. Biogeographist (talk) 19:17, 5 October 2022 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:AppleScript&oldid=1198879638"