| 1 | \section{\module{gensuitemodule} ---
|
|---|
| 2 | Generate OSA stub packages}
|
|---|
| 3 |
|
|---|
| 4 | \declaremodule{standard}{gensuitemodule}
|
|---|
| 5 | \platform{Mac}
|
|---|
| 6 | %\moduleauthor{Jack Jansen?}{email}
|
|---|
| 7 | \modulesynopsis{Create a stub package from an OSA dictionary}
|
|---|
| 8 | \sectionauthor{Jack Jansen}{[email protected]}
|
|---|
| 9 |
|
|---|
| 10 | The \module{gensuitemodule} module creates a Python package implementing
|
|---|
| 11 | stub code for the AppleScript suites that are implemented by a specific
|
|---|
| 12 | application, according to its AppleScript dictionary.
|
|---|
| 13 |
|
|---|
| 14 | It is usually invoked by the user through the \program{PythonIDE}, but
|
|---|
| 15 | it can also be run as a script from the command line (pass
|
|---|
| 16 | \longprogramopt{help} for help on the options) or imported from Python
|
|---|
| 17 | code. For an example of its use see \file{Mac/scripts/genallsuites.py}
|
|---|
| 18 | in a source distribution, which generates the stub packages that are
|
|---|
| 19 | included in the standard library.
|
|---|
| 20 |
|
|---|
| 21 | It defines the following public functions:
|
|---|
| 22 |
|
|---|
| 23 | \begin{funcdesc}{is_scriptable}{application}
|
|---|
| 24 | Returns true if \code{application}, which should be passed as a pathname,
|
|---|
| 25 | appears to be scriptable. Take the return value with a grain of salt:
|
|---|
| 26 | \program{Internet Explorer} appears not to be scriptable but definitely is.
|
|---|
| 27 | \end{funcdesc}
|
|---|
| 28 |
|
|---|
| 29 | \begin{funcdesc}{processfile}{application\optional{, output, basepkgname,
|
|---|
| 30 | edit_modnames, creatorsignature, dump, verbose}}
|
|---|
| 31 | Create a stub package for \code{application}, which should be passed as
|
|---|
| 32 | a full pathname. For a \file{.app} bundle this is the pathname to the
|
|---|
| 33 | bundle, not to the executable inside the bundle; for an unbundled CFM
|
|---|
| 34 | application you pass the filename of the application binary.
|
|---|
| 35 |
|
|---|
| 36 | This function asks the application for its OSA terminology resources,
|
|---|
| 37 | decodes these resources and uses the resultant data to create the Python
|
|---|
| 38 | code for the package implementing the client stubs.
|
|---|
| 39 |
|
|---|
| 40 | \code{output} is the pathname where the resulting package is stored, if
|
|---|
| 41 | not specified a standard "save file as" dialog is presented to
|
|---|
| 42 | the user. \code{basepkgname} is the base package on which this package
|
|---|
| 43 | will build, and defaults to \module{StdSuites}. Only when generating
|
|---|
| 44 | \module{StdSuites} itself do you need to specify this.
|
|---|
| 45 | \code{edit_modnames} is a dictionary that can be used to change
|
|---|
| 46 | modulenames that are too ugly after name mangling.
|
|---|
| 47 | \code{creator_signature} can be used to override the 4-char creator
|
|---|
| 48 | code, which is normally obtained from the \file{PkgInfo} file in the
|
|---|
| 49 | package or from the CFM file creator signature. When \code{dump} is
|
|---|
| 50 | given it should refer to a file object, and \code{processfile} will stop
|
|---|
| 51 | after decoding the resources and dump the Python representation of the
|
|---|
| 52 | terminology resources to this file. \code{verbose} should also be a file
|
|---|
| 53 | object, and specifying it will cause \code{processfile} to tell you what
|
|---|
| 54 | it is doing.
|
|---|
| 55 | \end{funcdesc}
|
|---|
| 56 |
|
|---|
| 57 | \begin{funcdesc}{processfile_fromresource}{application\optional{, output,
|
|---|
| 58 | basepkgname, edit_modnames, creatorsignature, dump, verbose}}
|
|---|
| 59 | This function does the same as \code{processfile}, except that it uses a
|
|---|
| 60 | different method to get the terminology resources. It opens \code{application}
|
|---|
| 61 | as a resource file and reads all \code{"aete"} and \code{"aeut"} resources
|
|---|
| 62 | from this file.
|
|---|
| 63 | \end{funcdesc}
|
|---|
| 64 |
|
|---|