- avoid update loops by checking values before emitting *Changed()
- check validity of user and root passwords when asked
- if root isn't going to be written, or re-uses the user password,
defer to those status checks.
- get username, password etc. from the config object, not the page
- jobs now depend entirely on config
- handle logic of "what's the root password" in Config
- 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.
- 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().
- 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.
On the "Users" tab, the user can choose a username. It was possible to
use 'root' as username, which led to an installation error, because
'root' exists already.
Added a new check to the username validation.
Fixes#1462.
- Having the widget do creation ties the step heavily to that UI;
start moving towards a state where we have a Config object (not
here yet; it still queries the UI part) that moves data around
between UI and ViewStep.
- move the explicit checking for non-empty into a specific
(normal) password check
- leave only the-two-fields-are-equal outside of the password-
requirements framework
- having non-empty is the same as minLength 1, but gives a different
error message
- the two explicit checks are the ones that handle *two*
strings as special cases; all the other checks from
the password-requirements system only handle the one string.
- the explanations under and around the boxes is noisy,
hard to size correctly (viz. issue #1202)
- use tooltips in almost-all fields instead
- add placeholder text to be more suggestive
- The only remaining functions in the file are string-related, so
rename to match their purpose.
- Drop this include file from most places, since they don't actually
use the string functionality at all.
- Make the explanations about 3 times as wide as the text-boxes
that they are explaining. This is partly moot because the
text-boxes have fixed pixel sizes in the designer file, but keep
it flexible for now.
