Re: Input for Upcoming Book
Re: Input for Upcoming Book
- Subject: Re: Input for Upcoming Book
- From: Steven Angier <email@hidden>
- Date: Sat, 18 Jan 2003 14:53:03 +1100
On 17/1/03 11:09 PM, "Charles Arthur" <email@hidden> wrote:
>
On Fri, 17 Jan 2003 09:10:38 +1100, Steven Angier <email@hidden>
>
wrote:
>
>
> Sounds like your target audience will be the advanced-to-expert scripter? If
>
> so, then step-by-step instructions of building "Hello, world!"-level
>
> applications won't really cut it, and if you are using AppleScript Studio,
>
> then you might find it difficult to build anything much bigger.
>
>
I have to *really* disagree on that. Here's my input: AStudio is *very*
>
powerful - arguably moreso than Applescript on its own. First of all, you
>
can prototype apps very quickly with it. But more than that, you get access
>
to not only the terminal shell, but also to Cocoa methods
Why not just use Cocoa? Apple has made that much easier than using
AppleScript Studio. That's what Project Builder and Interface Builder were
really purpose-built for (visually connecting inlets and outlets etc.) --
and there are plenty of books available for Cocoa development.
>
- so that you can
>
create real preference files (of the com.X.x.plist form) which you can read
>
and write, for example.
Personally, I don't see any value in having this type of preference file.
For a long time, our preference files have been either text-based
label-value pairs (the Unix way), or stored AppleScript objects -- the ideal
data medium for AppleScript applications. Both of these formats still work
and are "real" enough -- both easily editable. They just aren't Apple's
flavour of the month.
>
And you can do anything, through calling Cocoa
>
methods, that you could with raw Cocoa, but through the rather easier
>
medium of Applescript. You can create FBAs, or fully-fledged apps. And you
>
can design apps with Apple-quality UIs (if you're that good at designing
>
interfaces).
AppleScript Studio has some severe limitations -- the largest of which (to
me) is the inability for the various scripts to share data. This effectively
forces the entire project into one main project file, and the inevitable
gigantic conditional statements make the event handlers cumbersome to work
with.
The second major problem (as I see it) is the inability to simply reference
a window item by name, index or id -- in order to target a window item, your
code must traverse the entire window object hierarchy until you reach the
target object. For example, in FaceSpan you could just refer to "window item
3 of window 1", whereas in AppleScript Studio you have to refer to "button 3
of view of tab view item 3 of tab view 1 of window 1". FaceSpan would
resolve the reference. Studio can't.
The third problem is the abandonment of AppleScript conventions such as
error messages/error codes in favour of Cocoa conventions (e.g.
"NSReceiveEvaluationScriptError:4" instead of "Object not found -1728" or
similar).
>
iPhoto 1 was built with AStudio, I believe.
I have heard that rumour as well. But I can find no evidence to support
this. The package doesn't contain any AppleScript files that I could find
(apart from mail.scpt). Though the poor performance of the application would
indicate that it is an interpreted language, this does not appear to be the
case.
>
I think too that this book is going to be a huge project, and its audience
>
very hard to define. But it should definitely include AStudio - if it's
>
good enough for NASA scientists modelling jet engine noise
>
(http://www.apple.com/hotnews/articles/2002/10/craighunter/) I think it's
>
worth a look.
To be sure... However, NASA isn't modelling jet engine noise with
AppleScript Studio, they just seem to be editing the config files for their
Unix tool which does.
Steven Angier
Macscript.com
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.