- It is the requirements model (checking) that reports progress, and now
the model is accessible (ask for it with requirementsModel(), make the
messages come from there.
The requirements-checker in the Welcome module was not connected
to the module-manager's idea of what the requirements are, but
the *next* button was. So you could get in a situation where the
welcome modules' requirements were met, but **other** modules failed:
no display of the problem, and a disabled *next* button.
Rip out the welcome module's requirements-checking model, move it
to the module-manager, re-do the signals between the lot.
- The architecture of letting someone build up a list of requirements
from data emitted by the ModuleManager is broken: if it gets loaded
later, it will miss data; passing around complicated objects is
no fun anyway. Get rid of it, on the way to "ModuleManager has
its own model of requirements".
- Give the ModuleManager a RequirementsModel -- that is the source
of truth about the module-requirements of the modules managed
by that particular ModuleManager.
- Let the RequirementsChecker operate on a given RequirementsModel.
- The requirements are collected by ModuleManager, checked
by an internal RequirementsChecker and changes to the
requirements state are all signalled from ModuleManager.
By connecting the requirements in the welcome modules' Config
only to their own configs -- and immediately checking them,
which is bad on its own -- we end up with a disconnect between
what the ModuleManager says about requirements, and what
the welcome modules report on.
Doesn't compile (but I need to get it off this machine)
- Prepare to implement a picture-based slideshow alongside QML
- Split QML loading into the slideshow component
This might be good prep-work for moving QML loading out of the QMLViewStep as well.
fully implemented:
* loading of a live map, ESRI based, zooming & dragging possible
* IP address is translated to map coordinates
* loading of the map centers to the obtained coordinates, with a marker set
* coordinates are translated to a timezone, label visible at bottom of the map
* mouse movement will show changing coordinates
* clicking on new location will center map there, marker moved too, timezone label adjusted
* hasInternet switch set to either load Map.qml or Offline.qml
not done:
* get hasInternet status
* fill the fine-tune 181n.qml with proper locale & language data
* connect the obtained timezone to globalstorage
comments are left in the various files for what needs attention/changes
Improve testing framework while adding tests to rawfs to double-
check that the conversion (for Python 3.3 compatibility) of
capture_output is correct.
- If a module has tests/#.global or tests/#.job, these are used
as arguments to a test-run of loadmodule (which reads them
and runs the module with that configuration).
- This makes the old python-loading test and test-runner entirely
obsolete, so remove them too.
- By default, try to use DBus service to keep Calamares unique
- The older implementation via KDSingleApplicationGuard is still
available, just not used by default.