- Move the actual checking into a separate object with some lifecycle-
management signals.
- Right now this is still single-threaded and blocking, so no net gain.
- Module dependency-checking is done in two phases:
first, catch any unknown modules that are listed
in *requiredModules* and bail out before loading
anything. Second, check that the modules required
by X occur before X in the sequence.
- Collect the failed modules, instead of bailing out on the first one
(this also prevents crashes caused by quit() called from a timer).
- Introduce a slot to report on failed module loading (no UI yet).
- Move type and rename it; put in Calamares namespace
- Emit signals from the viewmanager as results come in
- Remove state changing from welcome view step based on its internal
requirements checking (for now this breaks progressing past the
welcome page)
- Log checking of the requirements
Introduce a method checkRequirements() into the module system so that
individual modules can do their own checking (as opposed to stuffing
it all into the welcome module).
- Was marked incomplete and unused; none of the existing modules
set any requirements, and the descriptors are not set up to
hold the requirements information anyway.
- Dependencies are generally through globalStorage values, or if
there are dependent jobs they should be created in-order by one
source (e.g. though a View or a subclass of CppJob which overrides
jobs() ).
- It is the responsibility of deployers to formulate a settings.conf
that includes all the required modules.
- A 'real' dependency system is going to lead to the introduction
of interface-definitions and a great deal of complexity, for a
use case that can be handled with careful deployment instead.
In order to avoid deep copies, Qt containers over which we iterate must be const
The remaining unported cases require qAsConst (Qt 5.7) or std::as_const (C++17)
Module descriptors are now module.desc, no configuration allowed inside.
Module config files are <modulename>.conf, installed in
share/calamares/modules.
settings.conf is read from /etc/calamares, then share/calamares, and if
running with --debug also in the current dir.
Module config files are read from /etc/calamares/modules, then
share/calamares/modules, and if running with --debug also in
src/modules/<modulename> relative to the current dir.
Now linking with -Wl,--no-undefined!
Moved find_package KF5 from the root CMakeLists.txt to the partitioning
module where it belongs. KF5 deps should be limited to plugins.
Lots of random fixage to make stuff link.
Removed CalamaresApplication reference from Settings.
Removed the use of AbstractPage, we don't need it right now.
