Re: Another appleScript WIKI question
Re: Another appleScript WIKI question
- Subject: Re: Another appleScript WIKI question
- From: has <email@hidden>
- Date: Thu, 13 Apr 2006 00:52:23 +0100
Stockly, Ed wrote:
>As I mentioned earlier I've been monitoring the wikipedia AppleScript page:
>
>http://en.wikipedia.org/wiki/AppleScript
>
>Lately someone posted this in the section on Open Scripting Architecture:
>
>"Under Mac OS X, the JavaScript OSA component remains the only serious OSA language alternative to AppleScript, though the Macintosh versions of Perl, Python, Ruby, and Tcl all support native means of working with AppleEvents without being OSA components."
>
>Is this correct?
Depends on your definition of "serious OSA language". If you mean "supports most or all of the OSA API and is a shipping product" then I think the answer is probably "yes". *However*, there's a great big caveat to this, because JavaScriptOSA has some pretty serious design flaws that cripple its ability to construct and use application references and commands correctly. So if you mean "actually works properly" then you really have to discount JavaScriptOSA until such time as these problems are resolved.
The only other "finished" OSA language components I know of are those by Philip Aker, but AFAIK they only implement the minimal set of core OSA functions (load, store, compile, execute, display) and not more advanced features like event handling that are needed for stuff like folder actions and Mail rules. So they're only a limited alternative.
Now, there is the question of UserTalk, which was the very first OSA language released (predating even AppleScript), but whose OSA support rather fell by the wayside over the years as UserLand moved into the web programming field instead. The Frontier kernel was released as open source in 2004 (see frontierkernel.org) and I believe there's been discussion about getting its AE/OSA support up to scratch, but I really don't know what the state of play there is at the moment. Someone like Matt Neuburg could brief you on that as he's a Frontier fan.
The only other projects I'm aware of are Bill Fancher's OSAPython, which actually got pretty far along but is dead in the water these days, and my own MacPythonOSA, which is also pretty far along but isn't quite at the stage where it could safely be turned loose on the general population [1]. Overall, over a decade
<rant>
I have to say that the pathetic state of third-party OSA support today is an absolute bummer to see, especially knowing just how much potential there is to this kind of technology. Unfortunately, while third-party developers certainly deserve some of the blame for their lack of enthusiasm or interest in the subject, IMO most of the fault belongs to Apple for failing to evangelise the technology or, more importantly, provide the necessary documentation and advice on how to implement OSA language components in the first place. This stuff is a right PITA to figure out all by yourself, and given the choice between beating your head against a brick wall or going off and doing something much more fun and interesting, 99.999% of programmers will not unreasonably opt for the latter.
In my case, I had to spend absolutely ages poring through all the documentation, examples, and other folks' attempts that I could dredge up in order to figure out how to put an OSA language component together. But still haven't worked out all the necessary details and have gotten sufficiently frustrated by the whole business that I've little enthusiasm for finishing it these days. (I'd be happy to provide help and advice to any fresh bodies that wanted to take it on though.)
</rant>
On a brighter note, while third-party OSA support may be in a pretty sorry state, third-party application scripting support is in much better shape these days. OSA gives you some nice features, but its absence ultimately isn't that big a deal since application scripting is probably 80% of the reason folk use AS in the first place. Perl, Python, Tcl and Ruby [2] all provide application scripting bridges, although the Tcl and Ruby [2] bridges are pretty low level. Mac::Glue may not be to everyone's tastes, but it's been around for years and is actively supported, while appscript is pretty mature now and a 100% genuine alternative to AppleScript for application scripting (appscript is even superior to AS in some respects).
As for the other 20% of AS use, Studio is basically a non-issue since most other languages have direct Cocoa bindings already, while things like Folder Actions and Mail rules can still be managed with a bit of old-fashioned string and glue to lash AS and other languages together; for example, appscript includes a quick-n-easy toolkit for wrapping Python code in scriptable faceless applications that can be called from AS, and there's always the old favourite, 'do shell script', of course.
So things could certainly be a bit better, but they're far from being hopeless either (and feel free to edit the wikipedia entries to better get this across:).
HTH
has
--
[1] I guess I could put out a binary of MacPythonOSA in its current state - along with various caveats and warnings - if anyone wants to play with it. Let me know.
[2] BTW, I would be interested in a joint effort to port appscript to Ruby if any experienced Ruby coders would like to take it on.
--
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