Re: Fun and games with Applescript "Standard Suite" in Cocoa app
Re: Fun and games with Applescript "Standard Suite" in Cocoa app
- Subject: Re: Fun and games with Applescript "Standard Suite" in Cocoa app
- From: Brian Webster <email@hidden>
- Date: Sat, 25 Aug 2001 22:05:20 -0500
On Saturday, August 25, 2001, at 02:51 AM, Neal A. Crocker wrote:
I figured I'd have to make use of NSScriptSuiteRegistry,
eventually, given my ambitions for the script shell I'm
developing, but I was hoping there was some simple way to
prevent the loading of the Standard Suite (perhaps by changing
some Build Setting or Application Setting in PB). If I could
prevent its loading, then I could copy the NSCoreSuite.script*
files out of the Appkit framework (or wherever they live), hack
them, and include them in my script shell project.
Well, I don't think this is doable by means of an Info.plist
entry or anything, but it shouldn't be too hard to implement by
subclassing NSScriptSuiteRegistry. You'd just have to overload
-loadSuiteDictionary:fromBundle: and filter out the suites you
don't want, and then load your own manually.
Now let me try to wrap my head around your idea, since it
sounds pretty cool, but I want to understand fully. So say I
wanted to use your tool. I would write myself an Applescript
and then "insert" it in your tool,
Yes. I'm currently storing the shell's script as
application.scpt in the shell package's Resource folder. The
scripter would create a compiled applescript and replace this
file to make an Applescript application. I also figure that,
at some point, I'll implement at least one alternative way of
"embedding" a script in the shell: I'll implement a "script"
property for the shell's application Applescript object which
can be set to contain a compiled script.
This idea reminded me of an old article from Apple's old
"develop" newsletter-type publication. I unearthed it from the
Applescript SDK, and also found a couple other articles that you
should definitely read if you haven't already. The ones I
recommend are titled "Open Scripting Architecture", "Inheritance
In Scripts", and "Attaching and Embedding Scripts". You can get
them from the Applescript SDK, or I could throw them on my iDisk
for you if you don't have a copy of the SDK CD or don't want to
tough out the 38 MB download.
along with my specification for the dictionary (done through
code, or through another interface?).
Creating *.scriptSuite and *.scriptTerminology files to place
in the shell package would be the hard way, but doable. I
actually was envisioning three different interfaces for the
scripter to manipulate the dictionary of the script application
(possibly to be implemented in parallel to give the scripter
maximum flexibility).
1) implement a dictionary property for the application
applescript object which contains a dictionary (read 'aete')
applescript object with appropriate element classes and
properties so that an applescripter can manipulate the contents
of the script application's dictionary.
It seems that the functionality of performing these
manipulations (i.e. your implementation of the script commands
that the scripter would use to perform the manipulations) is
present in NSScriptSuiteRegistry, but the full functionality you
need isn't publicly available. For example, there's no way to
simply add a single element to a class while the program is
running. Everything seems to be more or less immutable once the
program is running, except for the ability to load entire suites.
2) pass the "get dictionary" event used by script editors to
the script application's embedded script to handle. (I would
also like to implement a capablitity for the application script
to cache its dictionary when desired so that, if such a thing
is possible, the cached dictionary is passed back to a script
editor without starting up the script application and invoking
its "get dictionary" handler.)
3) implement some sort of extensibility for the script shell
that makes use of "plug-ins", and, possibly, shared
"frameworks" that would permit, among other things, extending
the application's dictionary.
The first two articles I mentioned have some very interesting
info on ways to do this fairly easily by attaching scripts to
various classes of objects. For instance, you could have a
standard button class that has an attached script that handles
various commands and retrieval of properties, and then you can
have a subclass with its own attached script which can override
the superclass's functionality, much in the same way one
overrides a method in an object oriented language.
This would give my script the ability to display various
graphical interfaces, with windows, buttons, whatever, maybe
even loading nib files.
Yes. By default, perhaps, such classes would not show up in
the dictionary, but there should be a way for the scripter to
"enable" them, or make them show up, and to use them. Assuming
its possible and I can figure out how to do it, I would like to
provide scripter the ability use both programmatic means of
creating and manipulating the user interface as well as to use
interface definition files (i.e. *.nib files). Either creating
a user interface programmatically within the script or loading
an interface definition file should cause the shell (at the
scripters discretion, and possibly with some required
intervention) to adjust the script application's dictionary
appropriately. Possibly, interface definition files could be
used as ingredients in the extensions I described above.
I don't think it would be a bad thing to have, say, the default
definition for a window along with the application having
windows show up as elements. If you don't use any windows, then
the app just won't return any windows if the scripter tries to
get them. It might be better to have them explicitly disabled
rather than explicitly enabled.
--
Brian Webster
email@hidden
http://www.owlnet.rice.edu/~bwebster