- add the "reuse user password for root" setting to Config,
make the UI page follow that setting.
- add the require-strong-password default and toggle settings to
Config; this is not well-checked yet.
On the widget / UI side, connect checkboxes only if they are
visible; refactor reuse-user-password-for-root settings.
- The enum for install choice was copied into PartitionActions and
used in the Config object; its definition does not belong in the UI.
- Chase the renamings required.
- add an option to select what button should be selected when the
partitioning module is started; TODO: the actual functionality is
**not** implemented.
- drop the previously suggested name, which didn't get beyond the
comments-in-the-config-file stage (but which intended to do the
same things as this one)
- add option to schema already, even if it's not implemented.
See #1297
FIXUP conf
The encryption widget (passphrase for disk encryption) should show
ok / warning / error whenever the state changes; this avoids
it showing up first with **no** icon (it should show a warning
when both passphrases are empty).
Both the KPMCore and the ChoicePage -- asynchronously -- were connected
to the nextStatusChanged() signal. So if the core said next was true,
that could end up communicated to the ViewManager, enabling the *next*
button in the UI.
Changing to the *erase* page generally triggers a KPMCore reload,
which later emits a `hasRootMountPointChanged()` signal, once the
layout is applied and the disk gets a root mount point. So we'd
get a `true` from KPMCore, which -- because it was connected directly
to the signal to the VM -- would override any other considerations.
Hook up both signals to an intermediate slot that just recalculates
whether the next button should be enabled, based on the state
both of the Choice page and whatever else.
- drop groups from the viewstep
- note that the Config object should also be in charge of creating
Jobs (but then the de-tangling needs to be completed)
- add tests of default groups loading
Doesn't compile because QRegExpValidator is a gui thing.
- This is a half-step: the ViewStep shouldn't do job creation either,
eventually it needs to be the Config object, but this is better
than asking the widget (UI) to create some jobs.
- When updating login- or host-name, or the autologin setting,
set it in GS as well. This is a minor improvement over doing
it only when leaving the page.
- Since the Config object isn't complete, there are leftovers in
the widget, which has a fillGlobalStorage() for the not-jobs-related
bits previously in createJobs().
- since the configuration is in the UI parts, we need the widget still
to load the whole configuration (until the config object is complete).
Create the widget before doing configuration; this is wrong. But now
we don't hit nullptr derefs all over.
- make the HostName textbox just a view on the Config's HostName
- make the username and login textboxes view onto Config
- query the Config rather than the UI for job data
- delay construction of the Page (widget) until it's needed
- hand the Config object to the Page on construction
This is prep-work for putting the configuration information into the
Config object, rather than in the UI elements.
- most of the things in utils/ are in the CalamaresUtils namespace,
let Permissions follow suit. Chase the name change in the
*preservefiles* module.
- add an `apply()` function for doing the most basic of chmod.
Note that we don't use `QFile::setPermissions()` because the
**values** used are different (0755 for chmod is 0x755 in the
enum value passed to `setPermissions()`).
