mirror of https://github.com/python/cpython
65 lines
3.1 KiB
TeX
65 lines
3.1 KiB
TeX
|
\section{\module{gensuitemodule} ---
|
||
|
|
Generate OSA stub packages}
|
||
|
|
|
||
|
|
\declaremodule{standard}{gensuitemodule}
|
||
|
|
\platform{Mac}
|
||
|
|
%\moduleauthor{Jack Jansen?}{email}
|
||
|
|
\modulesynopsis{Create a stub package from an OSA dictionary}
|
||
|
|
\sectionauthor{Jack Jansen}{Jack.Jansen@cwi.nl}
|
||
|
|
|
||
|
|
The \module{gensuitemodule} module creates a Python package implementing
|
||
|
|
stub code for the AppleScript suites that are implemented by a specific
|
||
|
|
application, according to its AppleScript dictionary.
|
||
|
|
|
||
|
|
It is usually invoked by the user through the \program{PythonIDE}, but
|
||
|
|
it can also be run as a script from the command line (pass \code{--help}
|
||
|
|
for help on the options) or imported from Python code. For an example of
|
||
|
|
its use see \file{Mac/scripts/genallsuites.py} in a source distribution,
|
||
|
|
which generates the stub packages that are included in the standard
|
||
|
|
library.
|
||
|
|
|
||
|
|
It defines the following public functions:
|
||
|
|
|
||
|
|
\begin{funcdesc}{is_scriptable}{application}
|
||
|
|
Returns true if \code{application}, which should be passed as a pathname,
|
||
|
|
appears to be scriptable. Take the return value with a grain of salt:
|
||
|
|
\program{Internet Explorer} appears not to be scriptable but definitely is.
|
||
|
|
\end{funcdesc}
|
||
|
|
|
||
|
|
\begin{funcdesc}{processfile}{application\optional{, output, basepkgname,
|
||
|
|
edit_modnames, creatorsignature, dump, verbose}}
|
||
|
|
Create a stub package for \code{application}, which should be passed as
|
||
|
|
a full pathname. For a \file{.app} bundle this is the pathname to the
|
||
|
|
bundle, not to the executable inside the bundle; for an unbundled CFM
|
||
|
|
application you pass the filename of the application binary.
|
||
|
|
|
||
|
|
This function asks the application for its OSA terminology resources,
|
||
|
|
decodes these resources and uses the resultant data to create the Python
|
||
|
|
code for the package implementing the client stubs.
|
||
|
|
|
||
|
|
\code{output} is the pathname where the resulting package is stored, if
|
||
|
|
not specified a standard "save file as" dialog is presented to
|
||
|
|
the user. \code{basepkgname} is the base package on which this package
|
||
|
|
will build, and defaults to \module{StdSuites}. Only when generating
|
||
|
|
\module{StdSuites} itself do you need to specify this.
|
||
|
|
\code{edit_modnames} is a dictionary that can be used to change
|
||
|
|
modulenames that are too ugly after name mangling.
|
||
|
|
\code{creator_signature} can be used to override the 4-char creator
|
||
|
|
code, which is normally obtained from the \file{PkgInfo} file in the
|
||
|
|
package or from the CFM file creator signature. When \code{dump} is
|
||
|
|
given it should refer to a file object, and \code{processfile} will stop
|
||
|
|
after decoding the resources and dump the Python representation of the
|
||
|
|
terminology resources to this file. \code{verbose} should also be a file
|
||
|
|
object, and specifying it will cause \code{processfile} to tell you what
|
||
|
|
it is doing.
|
||
|
|
\end{funcdesc}
|
||
|
|
|
||
|
|
\begin{funcdesc}{processfile_fromresource}{application\optional{, output,
|
||
|
|
basepkgname, edit_modnames, creatorsignature, dump, verbose}}
|
||
|
|
This function does the same as \code{processfile}, except that it uses a
|
||
|
|
different method to get the terminology resources. It opens \code{application}
|
||
|
|
as a resource file and reads all \code{"aete"} and \code{"aeut"} resources
|
||
|
|
from this file.
|
||
|
|
\end{funcdesc}
|
||
|
|
|