the toplevel package. This already worked for elements, but now for
properties too. Fixes#753925.
- Even better, the toplevel class (such as Finder.Finder) now inherits
the element and property dictionaries of its application class and has
the necessary glue to allow you to say
f = Finder.Finder()
f.get(f.name)
prefixes, any file that is skipped during a per-user install that matches
this set is *not* an error; Systemwide-only is a boolean that says the
package cannot be installer per-user.
pimp_update if it exists. Upped the version number to indicate this.
Fixes#731626.
- Added -V (print version) and -u (specify database URL) options when run
as a command line tool.
- 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:-)
