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 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 bootloader model knows about both rows and
devices, so we can look up both at once. The
existing implementation as a non-member was rather
sketchy and wasn't used except as support for
restoreSelectedBootLoader().
If the pakcage manager fails in some way, convert to a readable
error message instead of leaking the exception to the caller
(which produces a traceback, which is harder to read and less
informative)
Widgets are easier to style if they have a name, and easier to spot
in the widget tree as well. Give the requirements-checker
parts meaningful names.
SEE #1685
- in legacy mode, *id* can have an effect and leads to
"packagechooser_<id>"; if unset, uses the the module
instance id instead, still as "packagechooser_<instanceid>".
- in packages mode, *id* is not used and only the whole
module Id (generally, "packagechooser@<instanceid>")
is used, but in packages mode there's no need for other
packages to mess with GS settings for this packagechooser.
When the module is loaded and the viewstep created, it doesn't have a
module Id **yet**. That is set after reading more of the configuration
file. It **is** set by the time setConfigurationMap() is called,
so pass it on to the Config object then. This means that packagechooser
modules can skip the *id* config key and use the module Id.
