The existing API required calling the one constructor with
specific pointers (nullptr for a partition-from-free-space)
followed by calling one of the initFrom*() functions. This
is fragile design.
Use tag-classes to distinguish create-from-free-space and
edit-another-freshly-created-partition cases, refactor
to merge the initFrom*() methods into the constructors
and factor out the shared UI creation.
Callers can now use the tag-class to distinguish. While
here, adjust both callers to use QPointer, avoiding some
very specific dialog-on-the-stack crash possibilities.
When a partition is set as "freshly created", the dialog was
passing in newFlags() as the **already-active** flags on the
partition; then the caller was setting those same flags as
"set these in the future", so that afterwards, no flags would
actually be set (because they're already active -- see the
first sentence).
Now, fresh partitions have no flags.
This is intended for consumption by QML; the ViewManager object
acts as a proxy for a handful of global Settings values already,
so throw in global Logger values as well. A QML module that would
like to read the log file (e.g. for tailing it as part of a
slide-show) can get the path via this property.
Sending a Once to a logger that isn't enabled should not "consume"
that Once; it's still available for a subsequent logger that **is**
enabled (useful if you're using more than one log-level in a function).
Avoids a broken btrfs installation in the face of missing
configurations, and makes testing a little more safe by
neutering parts of the subprocess module in Python job-tests.
This allows injecting arbitrary Python code before
the script of a module is even run. For testing
purposes, that gives us a chance to modify existing
(internal) modules before the script (e.g. to test
subprocess calls).
This is related to https://invent.kde.org/neon/neon/calamares-settings/-/merge_requests/1
which adds .. the default things from the example configuration to the
configuration file KDE neon ships. The default layout doesn't add
any subvolumes at all, which seems to be non-functional.
If nothing is configured, complain and use /@ as the lone subvolume.
PARTITION_UNSAFE is a debug mode. It is not used in
production, because it allows you to pick an install
device that would be dangerous (e.g. the current / device).
Existing code kept two copies of a list of pointers,
and deleted pointers from one of the lists and returned
the other -- which now contains dangling pointers.
Refactor by applying suitable lambdas to a single
copy of the list; this avoids copying the list so
there is no danger of dangling pointers.
The only acceptable versions of clang-format are 8 and 9 for now
(until another round of big-churn-from-formatting, at which point
we'll update the required version).
clang-format-9 says:
SpacesInSquareBrackets (bool)
If true, spaces will be inserted after [ and before ]. Lambdas
or unspecified size array declarations will not be affected.
clang-format-10 changes part of that to:
Lambdas without arguments or unspecified size array
declarations will not be affected.
This means that 9 will only allow `[name]` for captures, and 10
will only allow `[ name ]` for captures, so they ping-pong all
the lambda's in the codebase back and forth. Just don't.
Various clang-format versions have different defaults and
don't understand the same options, so adjust to having
files per-formatting-version to patch things up.
- duplicate the file to .base
- drop 10-and-later setting that was commented out
- specific setting for lambda-formatting (this seems to be the default)
- The log **file** got every QDebug object, while stdout only
got the ones of sufficient logging level. A CDebug object checks the
logging level before writing anything -- so those already were
consistent, but any qDebug() in the program (not cDebug()!) would
reach the writing-function anyway, and so log to the file.
Fix this weird inconsistency by checking log-level just once,
for both writes.
- Map QtMsgType -- used by qDebug() and qWarning() -- to levels used
by Calamares in a consistent fashion.
- Drop unused log levels (INFO, EXTRA unused in any Calamares code).
The generic-build step runs an install to the host system; for artifact-
generation, we need it all centralized in a stage/ directory. Do that
separately for the KDE neon builds that produce the artifact.
