Re: on blocking target applications' GUIs (was Re: Tell Blocks Considered Harmful)
Re: on blocking target applications' GUIs (was Re: Tell Blocks Considered Harmful)
- Subject: Re: on blocking target applications' GUIs (was Re: Tell Blocks Considered Harmful)
- From: has <email@hidden>
- Date: Wed, 17 Dec 2008 20:17:51 +0000
Richard R?nnb?ck wrote:
The question is: Do you have scripts for which blocking user
interaction with
the frontmost application‹not the one running the script‹is
necessary for the
correct operation of your script?
[...]
Often I save scripts as application, just because that's the way a
user
expects to launch things. Nonetheless, the purpose of it is to drive
InDesign, AND to prevent user interaction.
Using osax dialogs to block a target application's GUI is a kludge
that only partially works around a serious deficiency in application
scripting, not the solution. For example, how do you prevent users
messing with the target application when there isn't a dialog present?
Answer: you can't; you have to rely on the user keeping their hands
off the application, if not the entire system, for as long as the
script runs.
I do Illustrator automation for a living, and I'm completely neurotic
about this issue, even when writing code that's intended to run on a
server with no human interaction at all. [1]
The problem here is that the Apple Event Object Model (which
determines the way that scriptable applications work) has absolutely
no concept of object ownership or session management [2]. i.e. Anyone
can create an object in a scriptable application, and anyone can
manipulate that object thereafter - regardless of whether or not they
have any business doing so.
The correct approach would be to allow each script to reserve
exclusive access to any application objects it needs to use for as
long as it needs to use them. For example, if script A opens document
B in TextEdit, *nobody else* - not the human user, not other scripts -
should be allowed to manipulate document B (or quit TextEdit from
under it) while script A is working on it. Once script A has finished
with these objects it can close or unlock them again, at which point
other clients are free to take their turn.
This is really, really basic common-sense design, and it's amazing in
a way that not only did it occur to the original AppleScript/Apple
Event Manager/AEOM designers and engineers, but that nobody at Apple
has done anything to address it since then. For all the criticism that
rival technologies such as (D)COM may (often rightly) receive from the
folk that use them, I'd be willing to bet even they don't make such an
elementary mistake.
I suspect the reason why nothing has been done is the failure of
AppleScript (and Mac OS's application scripting support in general) to
engage professional programmers with the same level of success as it's
had with non-programmers - if it had, I think things would have
improved long ago as the professional market wouldn't have tolerated
such deficiencies for very long, and would have made their objections
absolutely clear to Apple's own developers in a language they could
understand.
Now, I'm not going to get into what it would take to fix this problem
at the source, as that's a much longer and more complex discussion
which I've neither time nor energy for right now. The sole reason I've
brought it up here is to show that "fixing problem X will break my
workarounds for problem Y" is *not* a good technical justification for
not rectifying problem X (although it may be a political motivator for
not doing so).
...
Shane Stanley wrote:
In fact, I can remember several requests for some way toblock user
interaction with apps for the duration of scripts.
Absolutely agree; see above. The problem is in making it happen in
practice, as it needs to be supported on a per-application basis. So
not only do you need to alter the way that AppleScript does its
business, you also need to get application developers to modify all
their applications to support it as well. This might be easier for
Cocoa-based applications as Cocoa Scripting can be made to do some of
the hard work, but developers will still have to do the rest.
To be honest, I think if we're going to go that far, it would make
more sense for Apple to go right back to the drawing board and
completely rethink how inter-application communication ought to work.
If you're going to make major disruptive changes, you might as well
create a whole new independent system in parallel to the existing one,
allowing you to do it right this time without having to compromise it
for sake of backwards compatibility, and then leave developers and
users to transition over to it completely in their own time.
HTH
has
[1] Anyone who's done much Illustrator scripting will know that AI
uses by-index references everywhere, making it incredibly easy for
your script to lose track of objects even when it's the only one using
AI. In my case, I eventually ended up auto-generating unique ID
strings and inserting them into every single object's name. However,
while this kludge does give me a reasonable chance of reliably
locating objects again later on, it also creates new hassles of its
own - there's no such thing as a free lunch when hacking around the
inadequacies of AppleScript et-al.
[2] The closest the AEOM gets to any sort of permissions-based access
is transaction support, which the old-timey FileMaker users here may
vaguely recall. But transactions are really overkill for the vast
majority of tasks, as they also perform tasks like undoing all the
commands made during the transaction if one of them fails. That sort
of rollback support is completely unnecessary for most jobs, however,
and it's also incredibly complicated and time-consuming for
application developers to implement, which is why they never do it in
practice.
--
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