Re: Running ruby (utilizing appscript) from do shell script
Re: Running ruby (utilizing appscript) from do shell script
- Subject: Re: Running ruby (utilizing appscript) from do shell script
- From: Philip Aker <email@hidden>
- Date: Fri, 06 Jun 2008 06:52:21 -0700
On 08-06-06, at 05:41, has wrote:
For the integration with appscript, I can find some time to at
least look for solutions to any problems that might arise from
pairing these technologies.
There shouldn't be any problem using appscript within Philip's
components to control other applications, as appscript is just an
ordinary Python/Ruby module like any other. Don't try to use
appscript to control the application that's running the script,
however, as without full integration between the Apple event bridge
and the OSA language component this will almost certainly result in
you deadlocking both script and application [1].
The closest I got to a fully integrated OSA language component is
PyOSA, which you should be able to use with care. However, please
note that aside from being an unfinished developer release (and thus
subject to the usual caveats), I have no plans to develop it further
due to the various technical challenges facing the current design. I
do have plans for a multi-language successor, but there's no ETA on
that yet as RL is really busy at the moment and I won't be starting
any major new projects until the current lot are comfortably in the
can.
RL = RunningLate?
HTH
has
[1] OSA languages that wish to send Apple events to the host process
must do so via the OSA API. This is because the application's main
event loop - which is normally responsible for handling incoming
Apple events - cannot process new events while the OSA script is
running as both event loop and OSA language normally run on the same
[main] thread.
For the Carbon side of things, I'm not sure about that because you can
request the reply be sent to the queue or wait for it. Applications
can process AppleEvents on a thread. The limitation being if the event
affects or requires interaction with the UI, it has to repost it as a
CarbonEvent to the CE queue -- this is the crux of the "main event
loop" limitation. Also Phac handers work in normal Carbon apps.
Mail.app (definitely Cocoa) does it's AppleEvent handling on a thread.
As to whether or not this could be done from stay open applets or
droplets is another story -- complicated by what I think is largely
increased reliance on Cocoa frameworks for these items as of Leopard.
My theory is that if we could arrive at a convention for custom
attributes on events, OSABridge could delegate them appropriately to
appscript receivers but otherwise handle application events as usual.
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
Democracy: Two wolves and a sheep voting on lunch.
_______________________________________________
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