Re: SystemStatusBar question
Re: SystemStatusBar question
- Subject: Re: SystemStatusBar question
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 09 Mar 2005 18:17:45 -0500
on 2005-03-09 4:52 PM, Finlay Dobbie at email@hidden wrote:
> On Wed, 09 Mar 2005 15:56:28 -0500, Bill Cheeseman
> <email@hidden> wrote:
>> At the same time, I don't see anything hackish about GUI Scripting. It is
>> built on an official, public Apple API, the accessibility API.
>
> You're relying on the layout of the UI of a third party application. I
> personally consider the UI to be an implementation detail, and it
> could change from release to release. Surely that's something to be
> avoided?
GUI Scripting is to be avoided whenever there is a better alternative. There
is a long tradition in the AppleScript community of focusing on the data. I
first talked about it publicly in an article I wrote with Cal Simone for
MacTech in 1998:
<http://www.mactech.com/articles/mactech/Vol.14/14.02/AppleScriptScorecard/i
ndex.html>, but the idea has been around much longer than that.
Nevertheless, I have long felt that there is a role for scripting the GUI.
PreFab Player, released around 1994, I think, was the first and only GUI
scripting solution for the classic Mac OS (now, THAT was a hack!). It
continues to sell today to classic Mac OS users who simply must script the
GUI in order to get their work done.
Here are some pragmatic considerations. Although there are risks in using
GUI Scripting, they are manageable and I think you exaggerate them.
First, in my fairly extensive experience responding to help-desk questions
about GUI Scripting from users of PreFab UI Browser, I have found that most
scripters are seeking solutions to problems that can't be solved with
traditional AppleScript. Since the scripter controls the script, he/she can
revise it as needed when a new version of the target application is
released. Around half of our help-desk inquiries come from commercial
businesses, which suggests that there is a market-driven need for this
solution.
Second, the issue of version redesign isn't confined to GUI changes.
Although data format changes are less frequent, they aren't uncommon. I just
had to rewrite a bunch of my own scripts for OmniOutliner 3 due to data
format changes, for example -- GUI Scripting wasn't involved.
Third, and most important, the authors of the accessibility API already
thought of your concern. The primary target of the accessibility API is
developers of assistive applications for disabled computer users. Assistive
applications such as screen readers inherently depend upon the UI of third
party applications. To do so reliably in the face of version-to-version UI
redesign, they first ask the third-party application what interface widgets
exist, then they work with the widgets they find. A carefully-written GUI
Scripting script does the same, just as a carefully-written traditional
AppleScript script tests for the existence of data.
The proof of the pudding is that PreFab Player has had a very lengthy and
successful run in the classic Mac OS world. Many customers are mainstream
publishing companies and other commercial businesses who can and do save
mountains of money by developing automated AppleScript workflows using
applications that aren't scriptable in the traditional sense. That
commercial opportunity still exists today in Mac OS X, using Apple's own GUI
Scripting technology, which fills exactly the same role that PreFab Player
fills in the world of the classic Mac OS.
To give this a Cocoa link, let me point out that the accessibility API can
be used in Cocoa applications. I've written a Cocoa framework that makes it
especially easy to do. But I think we've exhausted this thread, unless you
want to continue it over on MacOSX-talk.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden