* Generic writer options
* Generic reader options
* All converter tools are equipped with writer options
* strm2gds is equipped with reader options already
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.
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.
- Massive performance improvement with debugger - trace was
eventually clearing the file to id map.
- UI updates on debugger did not happen because delayed
execution of functions got disabled.
* 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.
- The technology list now is synched with the salt package
manager so it's basically possible to include technologies
into packages.
This checkin also contains:
- A "NoDeferredMethods" class that blocks execution of deferred
methods in a region of code (preferably around message boxes).
This prevents side effects when message boxes are shown and
deferred methods are processed because of this.
That prevention method is used in the macro controller when
asking whether to execute autorun macros (that happens in
slots and must not interfere with deferred methods).
It's also used to protect the exception handlers.
- The tech manager dialog's refresh function used to crash
because of an invalid tech pointer.
Resolved the dependencies between MainWindow, TechController
and MacroController somewhat more.
* The macro controller now listens to the tech controller
for the active technology
* The tech controller has more responsibility now
* Some functionality has been taken out of the MainWindow
and put into the controller's implementation
The MacroController is the central facility for managing
macros and their views. The plugin framework has been
extended to support such a design.
In addition, some small bugs have been fixed related to
macro interpreters (specifically the DRC).
The respective new classes are RBA::Technology and
RBA::TechnologyComponent. This interface will replace
the current way of doing tech management from scripts
by using the "technology-data" configuration parameter.
First steps towards installer support. Specifically:
- basic installation methods, basic framework
- file utilities for directory copy
Side effect: temp directories of unit tests are
now cleared prior to test run.
This feature includes:
* Enhancements to tl::GlobPattern
(exact mode, case insensitive)
TODO: UTF8 support
* Enhancements to DecoratedLineEdit
(ESC key handling, Tab key handling)
Matthias Koefferlein