It is easier to put screenshots somewhere where
they can be searched-for, rather than requiring either
absolute paths (inconvenient to try out someone's
settings) or relative paths (because who knows where
Calamares will be run during testing).
The summary page can rely on the Config object to create
lists of relevant steps; this code was declared but not
defined / implemented for Config (but also not called, so
it was ok). This is basically shuffling bits around in
preparation for using the model directly, rather than
re-implementing the widget-creation code.
While here, split off the page-resizing into a free function
so that the code reads nicer.
- the page doesn't need to remember what step it belongs to,
if the step tells it when creating widgets.
- detach naming from the viewstep API that calls it.
The `partition.conf` file contains an EFI-size. The default is 300MiB,
but distributions might like to use a bigger (or smaller) value.
Apply the configuration consistently everywhere where we need
"the size of the EFI partition". Extend the internal method
to look at the configured size.
Apparently everyone shipping a squashfs image also has the tools
installed, because the error message reporting that the tools-are-
missing contained a reference to an undefined variable.
Fix that, and while here improve the error message so you
don't get a whole path as a title in the error message.
The slightly weird error-message construction is so that no
messages change and no translation work is needed.
All **other** modules fully specify libcalamares; only unpackfs
was importing shortcuts. Change to conventional usage (partly
because that's easier on the pylint implementation, partly because
it's then consistent with the rest).
Apparently nobody ever hit the else-branch here (because
each DM has exactly one implementation -- that's what the
check is there for!) because the logging of the error
itself would raise IndexError or ValueError.
This introduces a stub-implementation (fake) that mimics the
API offered by libcalamares (the library is actually exposed
to Python via Boost::Python, so it doesn't act like a C-extension).
Using that stub-implementation, we can check Python modules for
validity as part of the test-suite.
The stub-implementation is needed, because otherwise every
Python module already fails at `import libcalamares`.
- stub-implement the API that is actually used by the Python modules
- in globalstorage, be slightly smart about what keys are being
requested (so that e.g. all the modules that handle partitions
information get an empty list and can manipulate that, instead of
erroring out when they get a string)
- Make clear that the @ is a string-location, and how long the
pre-script is (although in practice, it will be either null
and 0, or the values set in the loadmodule executable).
