Re: Scripting a Cocoa app
Re: Scripting a Cocoa app
- Subject: Re: Scripting a Cocoa app
- From: Don Briggs <email@hidden>
- Date: Wed, 20 Mar 2002 09:30:27 -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.
>
Friends, we need more documentation and examples for Cocoa AppleScript
support.
Here's my contribution:
Go to:
http://homepage.mac.com/donbriggs
and download:
EasierCocoaSuites_v7.dmg.gz
>
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?).
Apparently, but watch out for overloaded terminology. It can fool you.
For instance, NSCoreSuite defines "color" so don't redefine it
in your suite. Try using "myColor" or some other hack.
>
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?
The existing docs point out some limitations on using data.
(AppleScriptLanguageGuide.pdf, page 120) If you need to
make NSImage scriptable, try making a subclass of NSImage
and adding script support to it.
>
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?
See the example above. It's a start. Under some conditions, you can
send a
"record", e.g.
{x: 5, y:10.5, w:20, h:40}
and it will "do the right thing" if the receiving class has Key-Value
Coding (KVC) support
for the record's keys "x", "y", et al.
That would require the methods:
-(void)setX: (int)someX;
-(void)setY: (float)someY;
...
so there's really the whole set of attributes to support.
>
Sketch's attribute are, unfortunately, very vanilla and don't do much
>
to elucidate this question.
Check. I'm left with the impression that it served as "proof of concept."
But, hey! It's really quite a concept!
>
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?
>
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.
This much seems clear to me:
if an ivar is to be shared, make it to-one relationships -- of
course. Otherwise,
if an ivar is one of the PPL scalar types (NSData, NSDate,
NSNumber, NSString) make it an attribute.
But otherwise, yes, it seems somewhat discretionary.
>
Are there efficiency concerns here? Are there things which are only
>
supported by one or the other that drive the decision?
Object specifier methods -- relationships get them; attributes just use
KVC.
>
Another thing I don't get is subclassing of NSApplication in
>
scripting. ...
>
>
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!
>
A modest suggestion: help make more examples.
And then nag Apple when:
you run out of documentation; or
something doesn't work as expected.
In this case, perhaps we need a set of examples of what NOT to do, as
well.
There was a pretty good book on basic electronics by Horowitz and Hill,
"The Art of Electronics". In addition to the normal "good practice"
example
schematics, it also featured "bad practice" example schematics with notes
as to why they didn't work as hoped.
Yeah -- I'll post a clearly labeled "bad practice" example later today,
same site.
Regards,
Don
_______________________________________________
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.