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: "Neal A. Crocker" <email@hidden>
- Date: Sat, 25 Aug 2001 23:28:52 -0700
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.
Thanks for the tip, but I have a basic Cocoa/ObjC question first.
Sorry if the anwser should be obvious, but if I subclass
NSScriptSuiteRegistry, how do I force classes that use
NSScriptSuiteRegistry to use my subclass instead?
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.
Thanks for the offer. I've seen those articles. I also have the
Applescript 1.3.4 SDK. Now what I need is the Cocoa equivalent...
Have you ever checked out an application called Smile? It's pretty
much a script shell such as I envision, with most of its behavior
implemented by an "application script". It's set up to serve as
script editor, but the application script could be replaced (by
setting the application's script property) to give it an entirely
different purpose. It's extendable In particular, its applescript
object hierarchy is extendable. It has a fairly sophisticated set of
user interface objects that can be instantied by scripts run by the
application (I mean "run" in the same sense that compiled scripts can
be "run" by Script Editor). Behaviour for the most of the objects in
Smile, including, in particular, the user interface objects, is
implemented by embedded class scripts and by embedded per-instance
scripts which override the class scripts. Smile has at least two
drawbacks which prompted me develop my own shell, both of which may
change in the future. 1) The user interface objects don't offer a
flexible enough set of hooks to allow scripts to implement behavior
for responding to user interaction. 2) Smile doesn't offer (as of
version 1.7.x) the option of packaging scripts as Smile "runtimes".
In other words, the Smile script devopment environment doesn't
provide the option of packaging scripts as script applications built
upon the very same shell upon which Smile itself is built. (However,
I've seen discussion on I-can't-remember-which forum or mailing list
(possibly applescript-users) involving one of (or the only?)
developer of Smile about whether future versions of Smile should
include such a packaging option.) Before deciding to create my own
shell, I considered whether I could get what I wanted just by
tweaking Smile to give it such a packaging option. Ultimately, the
limitations of the user interface objects convinced me I should
develop my own shell, but Smile remains very much a benchmark for
what I hope to achieve.
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.
Actually, there may be a roundabout way. There appears to be a
+setSharedScriptSuiteRegistry method . Thus it may be possible to
implement applescript commands which allow the building of an
entirely new dictionary, differing as desired from the existing
application's dictionary. The new dictionary could then be used to
simply replace the existing application dictionary (i.e. the set the
value of the application's dictionary property to the newly created
dictionary).
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.
Yep.
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.
Actually, much of the control over
what-is-promised-by-the-dictionary vs. what-is-delivered will be in
the control of the applescripter using the shell to package a script
application. I firmly hope, however, from the perspective of a
scripter who tries to make applications perform according to their
dictionary, that the scripter developing the script application
doesn't have a dictionary promising windows without actually
providing them. Be that as it may, on the assumption that the novice
applescripter will use my shell to package script applications of the
same variety currently packaged as standard script applications, I
figure that default dictionary should promise little more than an
applicaton object. Alternatively, I may design the shell so that, by
default, the dictionary promises windows, as you suggest, and, unless
the script application developer deliberatley intervenes, it delivers
windows. In other words, by default, if a user of the script
application uses applecript to direct it to make a window, it will.
Actually, this may be a better option, as it would show the novice
scripter who uses the shell to develop a script application obvious
ways to make his/her application interact with the intended user of
his/her application. Either way, for the sake of the novice script
application developer, the shell should by default go to great
lengths to keep its dictionary in sync with what it will deliver.
(One idea along this line is that the shell should, by default,
determine what handlers its application script implements and make
them visible in the dicitionary, if such a thing is possible.)
-
Brian Webster
email@hidden
http://www.owlnet.rice.edu/~bwebster