This commit deals with the deployment issue on Windows
where there is no global Ruby/Python installation and
the installer needs to package all required files.
The solution is to read the Ruby/Python path from a
file that is evaluated upon startup. The installer will
install these files together with the executable for
Windows. This feature is only enabled on Windows.
A specific issue occured: since the location of the
file needs to be determined, the path of the executable
needs to be known. The Ruby initialization requires the
path to be set very early, before QCoreApplication is
instantiated. But Qt complains in QCoreApplication::applicationDirPath
so that this approach cannot be used for this purpose.
The problem is caused by an implementation detail:
To monitor the lifetime of Qt objects, a monitoring
object is attached to them. This used to happen through
child objects but attaching such issues QChildEvents
which - if routed over script objects - will itself
required objects to be attached a monitoring object.
The solution is to attach monitoring objects through
QObject dynamic properties.
* Salt packages can host native Ruby and Python
libraries now. The "ruby_lib" and "python_lib"
templates provide such native libraries.
This way we can basically wrap every native
extension in such a package.
* Ability to supply binary plugins through
Salt packages as well.
With this change it is possible to bind signals to functions
accepting less arguments. For example:
def triggered():
...
b = pya.QPushButton()
b.clicked(triggered)
b.emit_clicked(True)
wasn't working before since triggered() gets one parameter
(checked) and the call fails. Now, additional parameters are
ignored.
* The solution consists of attaching a bridge object
to QObjects. If the host object is destroyed, the
bridge object will notify the script client
* The bridge object attachment is optimized so it
only happens if required (but still too often ...)
* The child object of QChildEvent gets a special
handling since this object is almost dead in case
of remove. This special handling consists of
a special, stripped class which is used to
only represent QObject in that particular case.
Matthias Koefferlein