* Fixed#591 (crash on Macro/Add Location)
The main reason was that the QSortFilterProxyModel is very sensitive
to the order of signals it receives from the proxy model.
In this case, dataChanged() must not be send between layoutAboutToBeChanged()
and layoutChanged(). This happened implicitly during load() of a macro while
scanning the freshly added folder.
* Fixed another part of #591: ability to disable template selection pop-up in macro editor. Tied to the tip window now - if this is dismissed, no template selection dialog will be shown.
- strmrun did not support x[rb] notation for file type
- x.y.py was rejected because y.py was taken as the suffix
- reason was extension() function for which there is
an extension_last() now
- but this function is no longer used as the lym::Macro
object is used now
With these fixes, unit tests pass with MacOS
(set DYLD_LIBRARY_PATH!)
1.) MacOS takes popen vs. pclose seriously
By using fopen we basically spoil the system and other popen
won't work.
2.) For system integrity, MacOS does not propagate DYLD_LIBRARY_PATH
to child processes such as sh. This has to be done explictly.
3.) Search the klayout binary in the right path (klayout.app/...)
4.) Reset KLAYOUT_HOME for less intervention by installed macros
The issue was: for MacOS/clang, the virtual format-specific
option structs had to be embedded in one compile unit (for RTTI).
In Windows this will lead to link errors since the DLL is not
reachable at build time for the generic reader/writer configuration in
the buddy tools.
The solution is to use GSI methods (provided for scripting) to
set the reader/writer options in a generic way that does not
require linking against the plugin DLLs.
The issue is with "dllexport": previously, dllexport was present on
exposed templates tool (= visibility(default) for gcc/clang). This
ensured MacOS compatibility since then the typeinfo is corretly
shared and dynamic_cast/typeid works.
For Windows, the "dllexport" equivalent requires the template
instantiations to be declared "external" which is a coding nightmare.
The solution is to provide separate macros for real (non-specialized,
not explicitly instantiated) templates (.._PUBLIC_TEMPLATE) which
is defined as empty for Windows and "visiblity(default)" for gcc/clang.
1.) Startup issue:
This is solved by making sure templates with virtual functions
are made visible in the DSO. This way, dynamic_cast is possible
across DSO's.
Scary: clang/MacOS wants the forward declarations be declared visible as well.
2.) Menu issue:
The best solution is to have only one QMenuBar. The navigator
now gets a synthetic menu bar composed of QToolButtons.