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.
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().
- the %4 is left-over from the feature-summary string,
- replace it with ""; don't change the source string
because that will break translations right now.
- Move variables closer to where they are needed
- Do the winnowing / selection always, but in unsafe mode return
the un-winnowed list of devices
- Massage build documentation a little
You'll need a VM with 2 disks to demonstrate:
- Configure Calamares to pick "none" as initial action on
the partition page (this is a safe choice),
- Enter partition page,
- No action is selected, and the next> button is greyed out.
- Click erase; notice next> is now available.
- Change devices, notice no action is selected, but next>
is still available. Clicking on it, though, does nothing.
When changing to "no action", update the next-button's
availability.
Avoid the extra indirection through the otherwise-unused
prettyGptType(const QString&), construct table of names
only on first call to avoid static-initialization order
(though that's not important here).
In particular, we need a separate Job class to set the label; this
is invoked after we formatted a partition, and when no other changes
to the partition have been requested in the Edit dialog.
The partition- and filesystem-label setting code was already there,
but not in the call to createNewPartition(); now we set the
FS label twice (once in the call, once afterwards)
When creating or editing a new formatted partition, allow
to set a filesystem label (16 chars maximum). Modify
the KPMHelpers to accept it as a new parameter. Partitions
created by default may get a meaningful label too.
