This enables font packages: packages can now provide fonts by
featuring a "fonts" directory with the font layouts.
This commit also adds the capability to dynamically add fonts.
The Glyphs system is decoupled from the application's system
path and the BASIC.TEXT PCell parameters are non-cached to
enable dynamic updates.
The bug was that a crash happened when a package was deleted.
Essentially that was an effect of too many message boxes asking
to run autorun macros (also a bug - solved by deferred execution
of the macro update). This is solved by putting the salt model
into a "under construction" state while the model is not updated
yet.
- 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.
- Adding/removing folders to packages now will
make them appear/disappear automatically in the macro
editor.
- Adding and removing files from folders will make
them appear/disappear in the macro tree.
- LayoutView should accept technology names that are valid only
- CellView now also sends an "active cellview changed" event when
loading a layout in "replace layout" mode.
Some bug fixes (description was not updated in tree,
base path of new tech was not set, dirs were not reused
for new tech).
Some enhancements (tech setup dialog's window state
is persisted etc.)
The tech controller now is indenpendent from the
macro controller. The macro controller is responsible for
pulling it's data from the tech controller. It's initialized
after the tech controller so it can do so.
The macro controller is also responsible to building the
menus.
The tech controller issues events that the macro controller
can listen to.
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.
Matthias Koefferlein