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 00:51:49 -0700
OK, this explains a lot about why you're wanting to do this
non-standard type of stuff. My quick answer is that to do this in
Cocoa, you'll want to subclass NSScriptSuiteRegistry, since that's
the class that handles all the loading etc. of suites. If you
subclass and use setSharedScriptSuiteRegistry:, you should be able
to control/modify the suites that are loaded. If you want total,
absolute control of the terminology, you could even override the
aeteResource: method and build the darn thing yourself, although
this would be more of a pain. Another option would be to ditch the
Cocoa Apple Event interface completely and use the Carbon one, which
would mean a little yuckier coding, but would give you access to
_everything_ and wouldn't prevent you from using the rest of Cocoa.
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.
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. Setting the
application's script property would cause the shell to store the new
value in the application.scpt file in the Resources folder of the
shell package. (Such a feature should be disableable by the
applescripter if he/she wanted to "freeze" the script application,
since, otherwise, it would be all too easy for users of script
application to gut it by using applescript to set the script property
of the application object).
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.
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 "plug-in" and "framework" extensions I envision
would extend exsting objects within the application's applescript
object hierarchy by providing them new element classes. Each
extension would provide the class description for the new element
classes (to be integrated into the application dictionary by the
shell), along with the code for resolving object specifiers involving
them. Scripts included in the extension would provide templates for
scripts to be embedded in new objects of these classes. These
embedded scripts would contain the object properties and handle
events sent to the objects. To give an example, an extension might
be used to define a document class as an element class of the
application object. For maximum flexibility, extensions might be
packagable in any of several forms, including, perhaps, bundles (or
actual CFPlugins, which I, as yet, know very little about). One form
I would consider very important is a simple compiled script.
Specifically, I feel it is important to implement the means for an
Applescript script to programmatically extend the object hierarchy of
a script application built using this shell. Given all this planned
flexiblity and the need for integrating info from different sources
into the application object hierarchy and applescript dicitonary,
some serious conseration will need to be given to handling conflicts
and making the system rational.
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.
Would I display these things through Applescript commands from
within my script? (i.e. 'make new window with nib file "foo"')
Absolutely, although, in the spirit of Applesript terminolgy
standards, the command might be more like 'make new window with
interface definition file "/..../foo.nib"'
So, it'd be kind of like writing a script that uses a bunch of stuff
written in a scripting addition, except that the "addition" would
actually be the code in the wrapper application,
plus extensions, which, much like scripting additions, might be
developed by third parties.
so the app could be moved from place to place in one piece without
needing to install a separate scripting addition to use the script.
yes, if it didn't use any shared extensions. Possibly, a simple fix
for such dependencies would be a "obtain private copies of shared
extensions" command or utility so that a shell application built on
this shell could become portable. Heck, such a command or utility
might be applicable to scripting additions too, if the shell could
load scripting additions from private copies. In fact, I vaguely
recall hearing of a utility that makes such things posssible for
classic script applications and classic scripting additions.
Am I on the right track here?
Yup.
By the way, to all you scripting addition developers out there, I'd
encourage you to turn your attention, at least partly, to creating
alternative packaging options for scripts. That would go as far
towards extending the capabilities of applescript as does the
development of scripting additions, but in a "different direction",
as it were. A notable example of such development would be
something by Leonard Rosenthal called, I think, "ScriptFBA" which
lets a scripter package a script as a classic faceless background
application.
--
Brian Webster
email@hidden
http://www.owlnet.rice.edu/~bwebster