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}{Jack.Jansen@cwi.nl}
|
---|
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 |
|
---|