In the sidebar, the "Install" step should be named "Set Up" when in
setup mode, which will be more consistent with the other UI texts,
including button labels.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
- This small header file contained a few unrelated typedefs.
Move those typedefs to the classes they relate to. This
**does** mean that some consumers need to #include something
else instead.
- Use type names more consistently.
Editorial: why are **pages** responsible for creating the jobs?
- Currently just moves a single enum, but this is prep-work for
moving the non-GUI parts of the module system into libcalamares,
to better support GUI-less operation.
- The only remaining functions in the file are string-related, so
rename to match their purpose.
- Drop this include file from most places, since they don't actually
use the string functionality at all.
- Even when Cancel is hidden, also disable it (prevents DBUS
triggers, for instance),
- Re-enable it when exec is over, if it's disabled then.
- simplify code a little.
- Use only utils/YamlUtils.h to pull in yaml-cpp and supporting code.
- When compiling with clang, turn off warnings that the system header
for yaml-cpp would generate.
- Using project() to set up the version is idiomatic for CMake
and more standardised than doing it by hand. Do retain the
RC flag, because that's used in other parts of versioning.
- Avoid crash due to invalid iterator, when modules
are removed due to missing requirements.
- Simplify code, factor out the determination of
which required modules are missing.
- These methods are used for multi-page view-steps, which are rare.
For all the others, just drop the empty implementation and defer
to the base class.
- 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.
In some cases, e.g. when calamares is used as an "initial setup" tool,
we may want to user to go through all the configuration steps in order
to end up with a usable system.
Therefore, disabling the "Cancel" button can be useful in this case.
This commit adds an option to settings.conf which disables this button
when set to "true". If the option is not present in the settings file,
the default behavior ("Cancel" button enabled & visible) is enforced.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
- A size of 64em has a value less than 1024, which is the minimum
size **in pixels**. The check doesn't make sense as-is and would
have to take the unit into account. Leave that to clients of
branding (e.g. CalamaresWindow, which already does this).
- Use DATA for the qml and branding directories (looks for qml/
and branding/<name>/ in those directories).
- Use CONFIG for the global settings and module settings (looks
for settings.conf and module/<name>/ in those directories).
FIXES#941
- Be more verbose when things go wrong while loading module-
configuration files.
- Allow more forms of paths to be specified. In debug mode, this
is mostyle helpful for the module test-loader.
- document new variable from the CMake module
- use it in libcalamaresui to simplify #include'ing the
header for the "all" extension.
Suggested by Denis Proskurin.
- Similar to the refactorings in Calamares proper, just split out
collecting the search paths into a static function. This makes
it a little easier to find places that will need expansion for
more-than-one-config-directory.
- There is more to failing out of loadModules() than just
emitting modulesFailed, so instead share the failure
code with the code after loading modules -- but don't load any.
- 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.
- The value set in module.desc was never stored for use,
but isn't an attribute of the instance, either. It belongs
with the descriptor, in ModuleManager.
Introduce the notion of emergency modules and emergency jobs.
Initial use will probably center around the preservefiles module,
and possibly umount.
FIXES#928
Any job can be an emergency job; emergency modules spawn
emergency jobs (but conversely, a non-emergency module
can spawn an emergency job explicitly).
A potentially emergency module is one that has EMERGENCY
(in CMake) or emergency: true (in module.desc) set.
Any such module must also set emergency: true in the
configuration of the module. This is to allow for
instances of a module that **don't** run as emergency
modules, alongside actual emergency ones.
