Do you want to make the most of your Mac applications? Like all operating systems, the Mac has many different levels of programming, and more than 80 percent of all applications built for OS X leverage AppleScript as an automation tool. In this introductory article, Matthew David tells you how you can best leverage AppleScript for your Mac applications.
Programming for the Mac: Introducing AppleScript
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I have to admit that the first time I used it, I absolutely fell in love with Applescript. It’s just the power it gives the user in the way it allows you to hook different applications together,
Is there anything similar for other platforms? Because if so, I’d be quite interested in checking them out.
Is there anything similar for other platforms? Because if so, I’d be quite interested in checking them out.
Well, there’s KDE’s DCOP(1) interface, which can be called from scripting languages, and has hooks for compiled languages. DCOP allows you to interact with the graphical applications KDE provides making it possible to automate tasks that require human interaction. There’s also Kommander(2) which is used to generate graphical applications that are DCOP-centric, allowing you to create GUIs for your scripts quite simply.
Then there’s Tcl/Tk(3), but that’s a little different from Applescript, though a viable alternative.
(1) http://developer.kde.org/documentation/library/kdeqt/dcop.html
(2) http://kommander.kdewebdev.org/
(3) http://tcl.sourceforge.net/
Is there anything similar for other platforms? Because if so, I’d be quite interested in checking them out.
Nobody has mentioned it yet, but on the BeOS you can operate *any* GUI program from the terminal if I’m not mistaken. With the gratis program called ‘HeY’ you can expose the handles programs use.
http://wiki.bebits.com/page/HeY
Also, if I’m not mistaken again, you can use any scripting language for which there are handlers installed on the system to script GUI programs.
I never used this stuff myself, so someone else might have to correct me; but if I’m correct, this is one of the features the BeOS still has over other OSes.
AmigaOS had/has ARexx.
“Is there anything similar for other platforms? Because if so, I’d be quite interested in checking them out.”
BeScript for BeOS maybe? http://www.bebits.com/app/1907
Is there anything similar for other platforms? Because if so, I’d be quite interested in checking them out.
Lets see. Python, Perl, Ruby? Not only are these more powerful, they are portable and cross-platform.
>Lets see. Python, Perl, Ruby? Not only are these more powerful, they are portable and cross-platform.
You forgot beter looking, well atleast for ruby and python.
>> Is there anything similar for other platforms? Because if so, I’d be
>> quite interested in checking them out.
> Lets see. Python, Perl, Ruby? Not only are these more powerful, they
> are portable and cross-platform.
I’m guessing that you haven’t read the article nor used AppleScript if that’s your answer… None of those languages are really designed to build GUI apps, nor do they offer the same integration with the OS and third-party apps that AppleScript does. For example, in perl, how would you go about doing this in less than a page of code:
-app must be able to have objects dragged to it
-user drags an email from Mail app to desktop icon
-mail is parsed for playable audio content
-audio content is loaded into iTunes library
You couldn’t in perl, nor ruby, nor python. Let’s realize that open source is not ALWAYS the right answer. Remember the parable about the hammer making everything look like a nail?
Exactly. I appreciate that Python etc. are probably more powerful from one point of view. But the whole point of Applescript is the way it lets you link different programs and the services together.
The application has to programmed to advertise its services to Applescript, although one can use GUI scripting when this isn’t the case. Because of this, I’ve always assumed that Applescript is fairly unique since I haven’t come across the idea of making a particular program ‘scriptable’
Yes, command line programs are ‘scriptable’ in this sense, but that’s not exactly what Applescript is designed to do. Command line stuff is all very well, but the majority of users spend their time using GUI based apps.
For example, a neat application of Applescript is say that you’re writing a document of some kind. You want to send it out using a mail merge kind of facility, but the program doesn’t offer it. With applescript, one is able to fairly easily write a script that will search a document for a particular word, and replace it with a name your address book. It could then print a PDF of that document and e-mail it to the person. The script then repeats this process for each of your chosen recipients.
Actually, there is a perl module that interfaces with the OSA (Open Scripting Architecture) on the Mac – which AppleScript uses to interface with native applications (OSA – not perl 🙂 ). However, I remember trying to use it a few years ago, and it was rather ackward. I ended up just using AppleScrpit instead. But, the fact is that you could in theory write bindings to the OSA interface for any language and script through it the way AppleScript does (and there are several other languages that do this exactly) but perl, python, ruby just don’t have it yet – and frankly, they weren’t designed to do stuff like that the way AppleScript was.
No, they are not. They don’t hook into any kind of applications like AppleScript Does. Can you control the Konqueror filer with python? I don’t think so. But with AppleScript you can control the finder.
There is no similar thing on other platforms. Perhaps VB a bit, but i don’t think you can do as powerful things as with AppleScript
Ummm. Applescript is quite different from the scripting languages that you mention.
Applescript lets you call certain functions of certain Cocoa apps, e.g. you can make iTunes list all the songs in a current playlist or make iTunes stop playing a song.
While the scripting languages you mention are great, they don’t have hooks into these Cocoa apps so they’re not like Applescript at all.
AFAIK Visual Basic aims to provide similar function that Applescript aims to provide but I might be wrong.
>> AFAIK Visual Basic aims to provide similar function that Applescript aims to provide but I might be wrong.
Oh, and, well I have used Visual Basic in the context of Visual Studio. I didn’t really come across any real hooks into other apps. I guess the Visual Basic (I dabbled with it briefly) in applications like Excel etc. does kind of do the job, but it is by no means as clear as Applescript. Also, it didn’t seem particularly good at communicating with other apps outside of Office.
Hooks into other apps? Just reference whatever DLL you want to use and code away. VS2005/.Net 2.0 will also support referencing EXE’s.
Why don’t we hear of shell scripting from Apple? They do have csh built in, and shell scripting has always been quite the powerful little tool.
http://www-128.ibm.com/developerworks/library/wi-wiisp.html?ca=drs-…
http://linuxdevices.com/news/NS9415221766.html
>Why don’t we hear of shell scripting from Apple? They do have csh built in, and shell scripting has always been quite the powerful little tool.
Apple does publish articles on shell scripting – along with the other scripting languages – on their Apple Developer Connection website. Anyway, AppleScript is much different than shell scriptping becuase it is primarily a language that supports the Open Scripting Architecture (OSA) on the Mac. There are other OSA languages (I can’t remember off the top of my head) but the goal is to provide a scripting architecture to manipulate other applications – in a way that is cross-application and very easy to implement and maintain in the application (you can just expose the application’s DOM structure and high-level methods).
Plus, each application automatically comes bundled with a dictionary – an embedded help reference – which is useful. You don’t have to run off to each application’s website in order to get the documentation to script it…
Anyway, those are some of the differences between shells, standard scripting languages, and OSA languages.
First of all IIRC there are (were?) some technical reasons why you shouldn’t use csh for scripting. Not all systems have csh, but all have /bin/sh so better use that for shell scripts.
Secondly, because to the shell Mac OS is just another Unix, shell scripting on the Mac isn’t any bit different from scripting on other platforms, so there’s nothing special Apple should need to say about it. Just get a book about it, or read the manpage (man 1 sh) and read some scripts.
Applescript has the ugliest syntax ever, and is verbose as hell, but it lets you turn boring GUI apps into work slaves (ha!), so that’s quite powerful.
Ulrich Hobelmann
The cool thing about Windows automation is that i can use any programming language with applications that expose COM interfaces… VB, python, c++, java, ruby, lisp… Is there a similar mechanism in osx or you can only automate with AppleScript?
Gnome offers zenity, a nice little app that presents various dialog boxes from the CLI or scripts. Alows one to draw calandars, entries, errors, progress bars, file dialogs, warnings etc., paired with the already mentioned scripting languages it’s pretty powerful. Not the same as AppleScript but worth a mention. Dunno about “hooking to other apps” probably not… maybe D-Bus?
Isn’t there PyCocoa library somewhere. And who told you one can’t write GUI apps in Python, Ruby, Perl?
So many comments, none of them with a clue.
Applescript is somewhat unique on several fronts.
– It really does strive to be somewhat human readable
<actual syntax>
tell application “Internet Connect”
connect
end tell
– It allows you to interact with the GUI for things that otherwise aren’t scriptable (interact with menus, push buttons, etc).
– It allows you to write simple applications, GUI-style or not, that abide by the above points.
There are most likely similar solutions for other platforms, but python, perl, and/or ruby aren’t it. Fact is, you would call those scripts/programs from your applescript if need be.
With AppleScript Studio you can create full-fledged GUI applications in AppleScript that behave like any Cocoa application.
For an example:
http://www.pcheese.net/software/macsig/
AppleScript is interesting and powerful for scripting applications from the outside and doing automation, but the REAL FUN begins when you script the Mac OS X object-oriented frameworks directly, with environments like F-Script or PyObjC. For this kind of stuff, AppleScript is weak.
F-Script: http://www.fscript.org
PyObjC: http://pyobjc.sourceforge.net
AppleScript is a pretty cool little tool on the Mac, for several reasons:
1. In the old Mac OS, it was the closest thing to a shell environment that the Mac had, and it functioned in a manner roughly analogous to bash with pipes: it can drive the applications that support it, extract data from one, use that as input into the next application, and so on. AppleScript lets you pull records from a Filemaker database and put it into an Excel spreadsheet.
2. As other posters have said, Python, Perl, etc. do not have the ability to manage data in this fashion. That said, these Unix-based scripting languages are much more powerful than AppleScript in many ways. AppleScript has rudimentary calculation and string support, no built-in regular expressions, no robust interface to networking protocols such as http, ftp, etc. One can build complete desktop applications in a Python + GUI toolkit environment, or Tcl/Tk. AppleScript does have a Cocoa binding via AppleScript Studio, so you can build AppleScript programs with Xcode and Interface Builder, but AppleScript’s limitations do present obstacles. (I’ve built some pretty cool Mac-based desktop apps in Tcl/Tk that could also be done in Cocoa/Objective-C, but not in pure AppleScript.)
3. What’s most interesting about AppleScript on OS X is that it is fully integrated into the Unix command-line environment via the osascript program. So while there’s a lot AppleScript can’t do, it certainly is possible to use AppleScript (even in a limited, non-Xcode kind of way) as a front end and then pass data on to Perl/Python/Tcl/etc. for the heavy lifting. It’s also possible to call AppleScript directly from a Python or Tcl script via the osascript tool. In Tcl this would look something like this:
exec osascript -e {
tell application “Finder”
display dialog “Cool”
end tell
}
This combination plays to AppleScript’s strength, which is as a “glue” language that plays well with other programs.
4. Finally, AppleScript is an excellent “first” programming language. Using the “English” syntax to automate basic things on my Mac soon led me into more robust languages: I have good proficiency with Tcl, some proficiency in Python, and so on. AS taught me the basics of programming logic, without having to decode the knotty syntax of more traditional languages.
AppleScript isn’t as versatile as some languages, but it’s very powerful within its environment. It’s hardly a toy.
… back when it was called ARexx and it was still a clever concept with much promise. Nice to see that 20 years later the idea lives on…
The linux/oss advocates here are missing the point. The cool thing about AppleScript is automation. To be able to code app interaction. for example, fetch a file list from the finder, pipe them to Quark express, build thumbnail gallery and page, save as HTML, upload to http://FTP... all driven by applescript. although we have hooks for Python to support AppleEvents and thus work this app interation, it still far from the easy to use experience of AppleScript, a language that anyone can understand, heck, I’ve seen designers make scripts to automate lots of things that would require a skilled python or perl code to do in other environments.
As for other options, I can remember from memory:
There is UserTalk from Userland Frontier (wasn’t it a osascript language?!)
There is AREXX on the Amiga
There is BeScript for BeOS/Zeta which expose BeOS messaging system as applescript like language… I find it strange, but it is a nice try.
The linux/oss advocates here are missing the point. The cool thing about AppleScript is automation. To be able to code app interaction. for example, fetch a file list from the finder, pipe them to Quark express, build thumbnail gallery and page, save as HTML, upload to http://FTP... all driven by applescript.
As I’ve already said in a previous post, you are able to do this with KDE’s DCOP interface. It’s not just some protocol that you can only use in C++, you can call it from the command line with the ever so simple command dcop or the graphical equivalent kdcop. If you need to push a button, get the text from a textbox, fill in a form, etc. from a shell script, perl script, C program, etc. you can do it with DCOP. You have the interaction, you just have to add your own language of choice.
Someone mentioned zenity for GNOME. There’s a similar program for KDE called kdialog. It’s pretty nifty, allowing you to create message bosex, buttons, sliders, pretty much any simple application you can think of is possible with kdialog.
Also, please don’t generalize the Linux/OSS equivalents, since the first poster asked what options were out there. It’s no surprise then that some people are going to give Linux/OSS options, since that’s what many OSNews readers use daily. The wonderful thing about Linux and Open Source is choice, ie you’re not bound to just Applescript, you can use whatever suits you best. If your programming language can perform a system call, it can use DCOP. Don’t forget, if it weren’t for Open Source, Darwin, FreeBSD, and all the other OSS projects Apple’s borrowed from, OSX might have sucked.
ops sorry if I was misunderstood. I was just pointing differences between both architectures, not trying to start a flamewar. anyway, thanks for the DCOP entrypoint, I am reading about it at this very moment.
I am not in any way one of those that disagree with F/OSS and I also don’t put them in a melting pot.
learning from your comments. Also any language can implement OSA, I know only two however, applescript and frontier…
iTunes is not a Cocoa app.
Applescript does not rely on Cocoa…
Allow me to point out that there is a huge difference between AppleScript and OSA. OSA is Apple’s framework for allowing GUI applications to be scripted through the use of a set of hooks into the application that allow OSA-aware programs to peek into the app’s state and data structures and to tell it to do things. It is very different from scripting languages like Python and Ruby in that it is not a language at all.
AppleScript is the “official” language of OSA, although there are a couple others which can be used with OSA – F-script and JavaScript, for two. Normally, people think of AppleScript and OSA as synonymous, which is unfortunate. There’s some debate about the value of this language, and the debate often gets muddled because people don’t recognize that AppleScript and OSA don’t have to be the same thing. But whatever you think about AppleScript/OSA, you should recognize that comparing AppleScript to other scripting languages is perfectly valid.
In fact, I encourage it. Maybe it will convince Apple that they should quit wasting resources on trying to get the stillborn travesty that is AppleScript to take off, and that they can change the official OSA language to something usable, like JavaScript or Lua or something.
No, they are not. They don’t hook into any kind of applications like AppleScript Does. Can you control the Konqueror filer with python?
Oh yes you can!
And you can control Konqueror from ruby and other lanaguages too. Here is opening a URL in Konqueror from ruby:
konqueror = DCOPRef.new(“konqueror-11145″,”konqueror-mainwindow#1”)
konqueror.openURL(“http://www.kde.org“)
The number in ‘konqueror-11145’ means a specific running instance of konqueror. You would need to you the kdcop app to find out this number.
Some KDE apps only ever have one instance running, like klipper the clip board and you can set the contents of the clipboard like this:
klipper = DCOPRef.new(“klipper”, “klipper”)
klipper.clipboardContents = “Here is some text..”
But DCOP doesn’t have the concept of object specifiers like AppleScript, for accessing simple structures and properties/attibutes. DCOP just has interfaces with functions exposed that you can call from a scripting environment. It’s up to the programmer writing an app like KWrite to implement suitable DCOP functions for accessing word 4 on line 3 of a document, there isn’t a standard way of doing that.
The main advantage of AS is that one does not need a degree in computer programming to use AS. I am a virologist and I don’t know how to code anything. But I have used AS successfully in Filemaker Pro to simplify the use of databases I have designed. E.g., to link up to other AS savvy applications and get information from the Web. I believe, AS was initially designed to help the everyday computer user to become more efficient at using it and for that it works great. What I like about AS is that anyone (e.g a biologist) can discern the meaning of the script since it is ‘verbose’ and written in straight forward english. Now Automator in Tiger makes it even simpler to do many such tasks since it removes the need to write any code at all-just link the tasks together visually! ( http://www.apple.com/macosx/features/automator/ )
Cheers
How is automator related to AppleScript ?
Does it produce applescripts or another script language ?
You may find your answer here
http://developer.apple.com/documentation/AppleApplications/Conceptu…
and the links provided therein.
Cheers
Is very similar to that of pseudocode. It allows you to focus on the actual logic of the program instead of the process of translating human logic into computer lauguage.
Most users don’t really care if they had to type a few more characters: Most AS scripts are short. Nor do they care about maintenability or extensibility: they just want to whip up a script in a few minutes to automate some repetitive procedure. If you look at it this way, AS is perfect.
Perhaps the OSS community could design something similar to AS. We already have the underlying technology (DCOP etc.), we just need a more English-like syntax.
MS rules!!!