Re: Scripting a Cocoa app
Re: Scripting a Cocoa app
- Subject: Re: Scripting a Cocoa app
- From: Greg Titus <email@hidden>
- Date: Tue, 19 Mar 2002 18:24:28 -0800
On Tuesday, March 19, 2002, at 03:17 PM, email@hidden wrote:
Howdy, folks. I've spent the past half-day wading through the doc on
scripting support in Cocoa, as well as the Sketch example. Most of it
makes sense, but I'm left with a few questions that I'm hoping I can
get answered. I'm not experienced with AppleScript -- I read a book on
it a little while ago (AppleScript in a Nutshell, horrible book BTW,
really needs a good editor to go over the whole thing), and wrote a few
very short Finder scripts to automate my disk image making process
somewhat, but there are many things about AppleScript I don't "get".
So forgive any foolishness, please.
The big thing I don't get is what types of information I can return
to AppleScript, and how those types get coerced into things AppleScript
understands. Sketch, for example, defines attributes like xPosition
and fillColor that it defines to be NSNumber and NSColor,
respectively. AppleScript, presumably, doesn't know about NSNumber and
NSColor, so they must be getting coerced by somebody (right?).
They are coerced by the built in scripting support in Cocoa.
I didn't find anything about who does that, though, or what types are
and are not supported.
As far as I know, that isn't documented, but it is: NSNumber, NSString,
NSData, NSColor as basics. (Note NSDictionary is missing from this list!
But a workaround for this was posted recently to Apple's
applescript-implementors list, which you might want to check out.) Plus
you can always return objects that are defined as classes to
AppleScript, like NSTextStorage, NSWindow, et cetera.
Can I have an attribute that is an NSImage?
Not out of the box, but you could add a class for NSImage to your
scripting dictionary and add a category on NSImage with methods to
implement accessors for various things.
What about an NSData?
Yes, that is built in.
The Finder lets you set the frame of a window using a {x, y, w, h}
syntax; how would I make an attribute in Cocoa that worked the same way?
That's an AppleScript list, which Cocoa automatically coerces NSArrays
into. Returning an NSArray with 4 NSNumbers will work.
Sketch's attribute are, unfortunately, very vanilla and don't do much
to elucidate this question.
Another thing I don't get is the distinction between attributes and
to-one relationships. What governs one's decision regarding whether a
given property should be an attribute or a to-one relationship? Are
there efficiency concerns here? Are there things which are only
supported by one or the other that drive the decision?
Or is this largely an aesthetic choice, based on whether the property
"feels" like an innate attribute of the object versus a separate
object? The doc seemed to emphasize this distinction, while never
spelling out why the distinction existed in the first place.
It's _supposed_ to be largely aesthetic, but I've had all kinds of
problems with to-one relationships apparently not working. That may be
just my issue.
Another thing I don't get is subclassing of NSApplication in
scripting. Sketch, for example, defines an object "NSApplication" that
is a subclass of "NSCoreSuite.NSApplication". Does this effectively
hide the "NSCoreSuite.NSApplication" class for scripters of Sketch, or
will both be visible, or how does this work?
It's like normal subclassing. The "superclass" properties will still be
visible.
Furthermore, Sketch defines an attribute "orderedDocuments" for
"NSApplication", but doesn't implement it; it appears to inherit it
from NSApplication. Why is this necessary? It's an NSDocument-based
app; shouldn't this facility be handled automatically by Cocoa? If
not, why do no other inherited document-related things need to be
defined in Sketch's suite? I notice orderedDocuments is missing from
the terminology file; is its terminology inherited from the core suite,
even though it itself is not?
This is to tell AppleScript that the resulting class of orderedDocuments
from Sketch is Sketch's documents, not Cocoa's generic documents. (I.e.
the subclass defines the property to return a different class than the
base class property.) If you don't do this then AppleScript won't know
that asking Sketch for its "first document" will return something that
responds to "graphics", for instance.
How does the application script object "work", anyhow? How is it
designated as the top-level object that scripts talk to?
Built in to the Cocoa support...
Can one define other top-level objects in the same way, or is there
always just the one "application" object, and other things are accessed
via that object's relationships?
There is always just one top-level object, but it doesn't necessarily
have to be the application - that's just what scripters are used to
looking for in the dictionary.
What if I want my top-level object not to be an "application" object at
all -- can I do that?
Sure. [NSScriptExecutionContext setTopLevelObject:]. See the docs for
NSScriptExecutionContext.
Thanks for any help you can give a poor newbie scripter. A pointer
to a scriptable app with source that has more complex attributes and
relationships than Sketch would be very welcome. I didn't find
anything relevant on cocoadevcentral or stepwise, but if I just missed
it, please let me know!
Hmmm. I don't know of any publicly available app source much more
complex than Sketch.
Oh, wait. Ken just did a new Omni source release a couple days ago...
In OmniFoundation you will find a category on NSObject that applies
AppleScript records to object properties, useful for all sorts of
things - most prominently "make new foo with properties" commands. It
also has some code in there for generating AppleScript automatically
from object properties (see OmniGraffle 2.0 beta's "Copy as AppleScript"
feature).
In OmniAppKit you will find some generic mechanisms for putting scripts
on a toolbar and executing them. Also a replacement for Cocoa's built in
text suite called the "Extended Text Suite" which supports some more
attributes, adds a bunch of AppleScript verbs, and is able to coerce
lists and records of text properties into text itself, which lets you
actually manipulate attributed strings in a reasonable way from scripts.
(Something sorely lacking from AppleScript, IMHO.)
Most of this isn't application level stuff, but it ought to give you a
better idea of how the Cocoa AppleScript support is hooked in.
Hope this helps,
--Greg
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.