Re: Scripting a Cocoa app
Re: Scripting a Cocoa app
- Subject: Re: Scripting a Cocoa app
- From: Brian Webster <email@hidden>
- Date: Tue, 19 Mar 2002 23:02:14 -0600
On Tuesday, March 19, 2002, at 05:38 PM, cocoa-dev-
email@hidden wrote:
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?).
Yes, the types that are declared in the .scriptSuite file are
Cocoa types, but each of these is changed into an equivalent
Applescript type when values are returned from a Cocoa app to a
script. So, an NSNumber becomes a integer/float in the script,
an NSColor gets turned into a list of three numbers, etc.
I didn't find
anything about who does that, though, or what types are and are not
supported. Can I have an attribute that is an NSImage? What about an
NSData?
I'm not sure that this is enumerated in any one place in the
docs. Off the top of my head, NSString, NSNumber (this covers
booleans as well), NSData, and NSDate are all supported.
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?
If you take a look at
/System/Library/Frameworks/Foundation.framework/Resources/NSCoreSuite.scriptSuite,
you can see that the window bounds attribute is declared as an
NSData<QDRect>. I don't know where this comes from, and it's
certainly not documented anywhere, but it's there and it seems
to work. NSColor objects also get returned to scripts as a list
of three numbers. However, beyond these two examples, there
doesn't appear to be any way of returning an arbitrary
descriptor, consisting of a list or a record or some other
non-standard data. This is a pretty serious limitation of the
Cocoa scripting framework and needs to be corrected in order for
Cocoa apps to be able to be truly first-class citizens in the
Applescript world.
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.
I don't know the definite answer to this question, but I've
always thought that making anything that's a basic type (string,
number, etc.) into a property and those that contain references
to another object a to-one relationship made the most sense.
I'm not sure if there's really any difference in the
implementation, though, since they both should just end up using
key-value coding.
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?
Declaring a subclass really _should_ hide the superclass from
the scripting dictionary, but it doesn't. They both show up,
but the subclass is the one that is used. I don't know what
would happen if you tried declaring two subclasses of
NSApplication - probably nothing good.
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?
The orderedDocuments method is implemented in Cocoa. It returns
the documents in the order they are from front to back, so that
commands such as "get name of front document". I believe Sketch
declares it only so that it can specify that it returns
SKTDocument objects instead of just plain NSDocument objects.
How does the application script object "work", anyhow? How is it
designated as the top-level object that scripts talk to?
I believe that the key to this is that the NSApplication class
is declared with the Apple Event code of 'capp'. The top level
object is the one that's declared with this code.
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? What if I want my top-level object not to be an
"application" object at all -- can I do that?
Theoretically, you could declare another class under the 'capp'
AE code and it would use that. Again, it's not very well
defined how the scripting system resolves multiple declarations
of the same Apple Event Code (this includes subclassing).
--
Brian Webster
email@hidden
http://homepage.mac.com/bwebster
_______________________________________________
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.