It works now as follows:
1) try to get theme information from the system, and if present us it.
2) if no theme information of the system is present, take the one from
the musredit_startup.xml.
Now it is possible to switch the icon theme for the menu and toolbar
separately.
Added the needed facility in the preferences which allows to switch
the icon scheme between plain and dark. This is needed for some OS
where qt doesn't provide the necessary information.
This allows to analyze the code by external code analyzers. Since a lot is adopted,
the version is changed to 1.4.3
Conflicts:
src/classes/PFitter.cpp
src/classes/PFourier.cpp
src/classes/PMsrHandler.cpp
src/classes/PMusrCanvas.cpp
src/classes/PRunAsymmetry.cpp
src/classes/PRunAsymmetryRRF.cpp
src/classes/PRunListCollection.cpp
src/classes/PRunSingleHisto.cpp
src/classes/PRunSingleHistoRRF.cpp
src/classes/PStartupHandler.cpp
src/include/PFourier.h
src/include/PRunListCollection.h
src/musrFT.cpp
Since the cmake tool chain is now stable, the automake tool chain is removed from musrfit.
This makes documentation and code less cluttered.
Conflicts:
configure.ac
src/Makefile.am
src/classes/Makefile.am
src/external/MuSR_software/Makefile.am
Added by default the dynamic search path '/usr/local/lib' to ROOT.
This is needed to find the necessary dictionaries for musrfit,
musrview, musrt0. Furthermore, added an option '--show-dynamic-path'
to these programs which allow the user to dump the currently used
dynamic search paths. This is potentially handy for diagnostics.
So far it was not possible to add Default Search Paths to musrfit via musredit if somebody delete all the predefined search paths. This bug is now fixed.
Up to now there has been an addT0 offset bug which resulted to the following situation.
Since the offset was wrong by '1', for the first addt0 the t0 of the file was used
instead of the one given in the msr-file. If these t0's are substantially different, the
adding of the runs was quite off, resulting in strong distortions at very early times.
Pant Amba Datt pointed towards this bug which is fixed now.
If neither QWebEngine nor QWebKit is found, do not generate an build
error anymore. Instead just show a default window stating that
the help system is not available due to missing Qt web libs.
Adopted the build system for the BNMR libs such that the generated files are found and can be installed. The BNMR lib mantainers (ZS, JK) are responsible for the functionality though.
