warning messages implemented for user & host names
move root password option box inline with password section
adjust background color according to text.length
hardcode color instead of kirigami colors
usersq is now usable, sets user, hostname & password correctly on install
warning messages & color changes not fully done yet
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).
- fsName was a QString (a copy) so it could be modified;
- the modification isn't really necessary.
- While here, pick up new PointerSetter convenience class.
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.
