On 9/12/02 6:59 PM, "_brian_d_foy" <[EMAIL PROTECTED]> wrote:
> i've been playing around with AppleScript lately. it's a nice language for > what > it's supposed to do. however, it's not any good unless the applications that > should be scriptable actually do what they say they should do. Yes, the more I play with scriptable applications (for testing & developing of my Mac::AppleScript::Glue module), the less consistent things seem to be. I discovered today that Photoshop and InDesign (both Adobe apps!) have slightly different syntax to open a document; further, one uses "current document" and the other uses "active document" -- they mean the same thing. The thing that drives me more nuts, actually, is that there are very few guides that really explain how scripting actually works in a given application. Browsing the app's dictionary using Script Editor is painful, and the printed guides aren't much better (InDesign's is 300-odd pages of nicely typeset snaps from the dictionary, with a few examples; Photoshop's is very small, gives you a *little* more background and higher-level explanation, but still leaves you in the dark for most things.) > i was hoping that Perl could do a bit of gluing between MacOS apps, but it > looks > like a lot of AppleScript support isn't all that useful for non-interactive > automation, > but some things are still hard in Perl even though things like TextEdit solve. Using Perl doesn't make it easy. But it makes me scream less to write procedural stuff (loops, if/else's) in Perl than it does to write it in AppleScript. And the fact that I can easily hook in things like File::Find, Data::Dumper, DBI, etc., make it worthwhile. > now the further bummer: since the apps don't do what they should be able to do > (according to what they advertise), no matter how awesome Perl is, it can't > get around that without lots of third-party modules. that's a lot to ask for > an > end user. I've always wanted an easier way to be able to handle module dependencies . I could pretty nearly imagine an installer for an app (or even a library) that downloads the required modules (from CPAN) behind a pretty installer screen. Or for that matter, if you're distributing an actual program (as opposed to a module), couldn't you just ship the needed Perl modules as part of the application bundle, changing @INC as needed? (I'm only guessing that this will work.) -- John Labovitz [EMAIL PROTECTED] www.johnlabovitz.com
