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
* Introduced "refresh" method of tech setup dialog
* Some refactoring -> tech management is part of
tech controller
* Macro category management moved to macro controller
The technology controller is a further abstraction and
is derived from the TechnologySelector. It will act
together with the MacroController and supply technology
specific information. Macros are part of that.
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).
- Shortcuts are honored and have priority over
search initiation. This is in particular important
for "*".
- "/" initiates search without yielding a "/" in the
text edit box.
- Now the help index can be installed with the app
Fallback is auto-generated index in app folder.
- The index can be generated by script with
RBA::HelpSource#create_index_file
- The index is read only when the help dialog
is opened (reduces start time)
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.
Previously, the "technology-data" complex configuration
value was stored in the configuration file, but not
accessible from scripts through Application#set_config
and Applicatiob#get_config. It was as pseudo parameter
that wasn't dynamically connected to the application
state.
Now it's handled separately as if it was a normal
parameter. This is just an intermediate solution
required because this interface is the only one
through which tech data is accessible from scripts.
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.
Side effect: the log dialog now has an icon
indicating whether there are errors or warnings.
A new utility widget has been introduced to
attach log messages (warnings/errors) to
dialogs. This widget is a QToolButton that
is invisible initially. It provides warning
and errors channels and can be fed messages.
If errors or warnings are fed, the tool button
becomes visible. If (directly) embedded inside
a QFrame, the frame's background will turn
red to indicate the region of interest.
The button can be pushed to read the log.
The button is called lay::AlertLogButton
and is found in layLogViewerDialog.h.
TODO: move to layBasic.
This solution will not only fix this issue but also turn
pairs of edges into "edge pair" objects. These objects
provide a somewhat better visualization for DRC violations
by connecting the edges with a filled region.
Single edges and clusters of more than two edges are
represented as individual edges.
Matthias Koefferlein