Re: [ann] py-appscript 0.21.0
Re: [ann] py-appscript 0.21.0
- Subject: Re: [ann] py-appscript 0.21.0
- From: has <email@hidden>
- Date: Fri, 4 Dec 2009 21:08:51 +0000
On 4 Dec 2009, at 17:49, email@hidden wrote:
> On Dec 3, 2009, at 2:43 PM, has wrote:
>
>> Announcing a new release of Python appscript, an easy-to-use Apple event bridge for the popular Python scripting language.
>
> Hello has,
>
> I was wondering if you had any plans to release a Perl version of AppScript?
No current plans, alas, simply because I don't have enough time available. In fact, there's several languages I'd really like to port appscript to, but these days I'm struggling to find enough time to keep all of the existing ports up to speed. (Py-appscript has the advantage that I use it daily for professional work; hence this update as I needed these fixes and improvements myself.:)
FWIW, in the absence of a pl-appscript bridge, there are a few other options you might want to investigate.
Mac::Glue (one of the longest-serving Apple event bridges) is bundled along with OS X's default Perl or can be installed separately from CPAN. It's not as as actively maintained or as good as appscript - the API is quirky and there are shortcomings in the way that it bridges AE types to Perl ones (though I suspect that's more an inherent Perl problem that Mac::Glue's fault).
Another option might be Scripting Bridge via PerlObjC or CamelBones. Again, SB isn't as good as appscript, never mind AppleScript, but it mostly works with most apps, so may be sufficient depending on your needs. I've not tried this particular combination myself though, so I've no idea if SB's own 'magic' (generating ObjC classes at runtime) is compatible with one or other of the Perl-ObjC bridges. e.g. I know the RubyCocoa and PyObjC bridges can handle SB, but I don't know if the Perl bridges have such deep integration with the ObjC runtime.
If you've time to spare, yet another possibility would be to try writing an pl-appscript bridge yourself. Assuming PerlObjC and/or CamelBones is reasonably capable, the easiest option would be to follow macruby-appscript's approach and create a thin native-Perl layer over objc-appscript's AEM... and AETEParser classes. The AEM classes are fully usable in themselves (they do all of the hard work of converting data between native and AE types, building object specifiers and sending Apple events) but, like AppleScript's chevron syntax, ain't so nice to use directly. The high-level 'appscript' layer merely adds some dictionary-driven syntactic sugar on top, tailored to suit the particular strengths and features of the host language (e.g. objc-appscript uses static .h/.m glue files; rb-appscript overrides the #method_missing hook at runtime).
Regards,
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden