Libraries now carry a technology association and
only libraries associated with the current technology
can be selected.
To enforce proper update, cancel() will be used upon
change of technology. This avoids side effects when
changing the technology without notifying the library
selection widgets.
The MainWindow::cancel method has been generalized to
cover the functionality of cm_cancel without the
exception handling.
This fix ensures that packages satisfying dependencies
for other packages come before these in the flat package order.
This is in particular important for macro packages where those
supplying libraries need to be executed before the ones
that use these.
If the documentation URL is relative it's either
taken relative to the package installation path or
to the download URL. This means that documentation
can be inside the package now.
Technologies and macros that come from packages
are indicated as such in their description texts
in the tech and macro editor.
Technologies and macros that come from packages
which are downloaded are readonly now. This will
prevent editing of downloaded packages.
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.
Matthias Koefferlein