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 effect was: while a message box was open
to indicate a change of a file, new file changes
accumulated new message boxes. Now, the message
boxes won't accumulate and new file changes
are recognized after the message box is closed
and files were reloaded. Changes not acknowledged
by reloaded are presented again if changes were
seen while the message box was open.
The effect was: when not having save options in the technology
setup (for example, when migrating from 0.24 to 0.25), it was
not possible to edit the save options page in the technology
manager because the data slot of the save options wasn't
initialized.
Reason: when a page was opened in the macro IDE,
the file to ID cache inside the Ruby interpreter
did not get updated. Hence there was no link
between breakpoint and page and the breakpoint
was ignored.
- Allow full 32bit for box width and height
and some other properties (for border case
testing - not recommended)
- Reduce arrays with step distance 0 to
dimension 1 - avoids overlapping instances
or shapes.
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.
- Include a copy of the unit test framework so we're no longer
depending on incompatible versions for Ruby 1 and 2.
- Avoid duplication of path entries in unit tests
1.) Wrong scaling of output when using output to layout A or B and
different DBU's were present
2.) A threading issue when delivering outputs to layout A or B resulting
in random crashes and weired behavior. This happened when threading
was enabled.
Bug: sometimes, if the files had different database units, the XOR
tool was showing differences while there are none.
This was due to a sloppy computation of the tile boxes. The solution
is to properly round the tile size to a common database unit and
to use a common effective size for both inputs.