- Allow setting the destination install directory. If this is set then
it is used for the modules, other items (header files, etc) are not
installed, and warnings are printed if the package would have liked to.
Unfortunaltey binary installs seem broken due to a tarfile bug (#721871)
or my misunderstanding of how tarfile works.
to lookup properties declared in base classes. Looking at it I'm not sure
what the official scope if the property codes is, maybe it is only the
(OSA) class in which they are used. But giving them global scope hasn't been
a problem so far.
Regenerated the standard suites, which are now also space-indented.
the Standard_Suite, but various other suites do expect it (the Finder
implements get() without declaring it itself). It is probably another
case of OSA magic. Adding them to the global base class.
within a certain context. Give them an _Prop_ prefix, so they don't
accidentally obscure an element from another suite (as happened with
the Finder). Comparisons I'm not sure about, so I left them as global
names.
Also got rid of the lists if declarations, they serve no useful purpose.
you to say something like "talker.count(want=Address_Book.people)" in
stead of having to manually create the aetypes.Type(Address_Book.people.want)
OSA type.
This is a first step towards regenerating the modules with newer, MacOSX,
versions of these programs, and using the programmatic interface to
get at the terminology in stead of poking in resource files.
could be responsible for various unexplained problems with Python/OSA
interaction over the years):
- Enum values were passed as their string counterparts. Most applications
don't seem to mind this, but some do (InDesign).
- Attributes have never worked (!), as they were incorrectly passed
as parameters. Apparently nobody uses them much:-)
create a temporary file. This fixes#688011.
Got rid of the install() method in macresource, and replaced it with
a resource_filename() method which will optionally decode a given resourcefile
(which may be applesingle-encoded) and return the real resourcefile.
Use this new method in buildtools to copy the correct resource file to
the bundle. This fixes#688007.
- Replaced bootstrap shell script with Python script. This means
standalone apps built with bundlebuilder will not work on MacOS < 10.1,
since we depend (again) on an installed Python.
- Add a hack to set sys.executable; the bootstrap script does os.execve()
with an argv[0] that's different from the actual Python executable
(it has to match the CFBundleExecutable entry in the Info.plist to make
the app work both from the Finder and the command line, and it has to be
the bootstrap script), yet a proper sys.executable is needed to spawn
auxiliary processes.
Jack Jansen
Raymond Hettinger
Just van Rossum