Go over the locale module again:
- new models that avoid weird casts and inconvenient iteration
- shared timezone data
- simple sorting and filtering
- simplify the map / QML version
FIXES#1476FIXES#1426
- test insert, remove, emitted signals
- test loading and saving of YAML and JSON
This shows up a big bug in the YAML saving code (which was never
used, it seems, anyway)
- the loadJson behavior did too many notifications, and was likely to
deadlock; write directly to the map instead and emit only once.
- the loadYaml method did something very different from its
documentation or intent.
- refactor into some free functions (out of the lambda's for connecting)
- introduce new method to call from onLeave(), matching previous
widget behavior
- we can do GeoIP and GeoNames lookups, **or**
- use Calamares's internal GeoIP lookup and country / city hints.
The online version is much more accurate, but costs more lookups;
in these examples, set it all to "offline" and document what needs
to change (code edit) to use the online version.
It's probably a good beginner job to introduce a bool in localeq.qml
to switch the behaviors.
- Config has suitable strings for displaying TZ information.
Use them and automatic bindings. Don't update the strings manually.
- Suggest online or offline TZ lookups based on what the distro wants.
Edit the QML to pick online lookups (needs access to the geonames
service, though).
- Drop the variables that point at config and geoip: the Config
object has a currentLocation, which is filled in by both the
configuration and any GeoIP lookup -- it doesn't have city
or country information though.
- status is a longer phrase
- name is a short human-readable name
- code is the internal code
Code that writes its own "Timezone set to" messages can use
the name, rather than the status.
- when no location has been set at all, there's no sensible TZ
to report; just leave it blank. In *practice* you won't hit this
code from the Calamares UI before a location has been set, because
the Config object is instantiated and then immediately configured,
but from tests or unusual UIs it could be.
- needs some massaging because Config otherwise depends on
ModuleManager which is a UI class (for the Reasons),
but we already have a BUILD_AS_TEST define for that purpose.
- demonstrate a nullptr deref.
- The Config object now uses the re-done models and timezone data
- most of the properties of the locale Config are unchanged
- much less complication in extracting data from the zones model
It's convenient when e.g. QComboBox::currentData() gets the key
"automatically", and the default role for that method is UserRole,
so let the value of KeyRole overlap.
The (renamed) class TranslatableString keeps a key value
(e.g. New_York) and a human-readable version around; the
human-readable one is passed through QObject::tr() for translation
on-the-fly.
- The models are overly complicated: **overall** there is just one
list of timezones, and we need various views on that list.
Start over with an empty model of regions.
- there **is** another source of information about the CPU,
so in the test use that to cross-check what hostCPU() says.
NB: it's probably a good idea to fall back on the same file
in hostCPU() for better accuracy.
- 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
- The configuration for writing the hostname (to /etc/hostname,
to /etc/hosts and possibly to systemd-hostname) is read-only,
because it comes from the config file and won't change after.
- 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 language code "ie" is not recognized,
- "ia" is, and it seems to be the post-war variant of
Interlingue, so we may want to rename / relabel.
The testEsperanto test -- now split into scripts and
esperanto -- would have picked "ie" out of the list
because it does map to C locale.
The TODO said it was unused: it **is** used, but only in
a very limited scope. Drop it from jobs where it wasn't
useful (e.g. those that just return prettyName(), outside
of the partition module).
This builds some machinery so that we can create
a detector for member-functions (methods) named <whatever>.
Use the macro to build the machinery:
DECLARE_HAS_METHOD(myFunction)
then after that,
has_myFunction<T>
is either std::true_type or std::false_type
depending on whether T has a method myFunction.
- 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.
Previously, we check for RCC support every single time CMake runs.
This is slightly wasteful, and it wasn't being done right anyway.
But it's moot because:
- Calamares supports back to Qt 5.9
- Qt 5.9's version of rcc (at least, 5.9.7) **does** support the
command-line argument `--format-version 1`
- Everything newer does too.
Simplify translations a little, too: just use autorcc rather than
building things by hand.
- The sources were in src/calamares but processed and generated
in libcalamares, which is weird at best.
- Generate an "extended" version header.
- Use the extended version in the logger and nowhere else.
- While here, minor coding style cleanups
The overall change here means that after running CMake, only
Logger.cpp needs to be rebuilt (if the extended version has
changed) and not a handful of other files that don't need the
full version number, but do happen to include CalamaresVersion.h
- Very rarely do we need the full-git-version of Calamares,
so split that into a separate header with a little trickery.
- In the "normal" version header, drop the full-git-version values.
- 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()`).
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.
With PR calamares/calamares#1357 the label of the "Manual partitioning" option
was changed, which introduced several downsides:
* The label is shown for UEFI and for BIOS installations.
* The mountpoint of the ESP is and should be distro specific.
* The label always mentioned GPT, which is irrelevant.
* The label should explain, what the option does, and not, what
problems can occur under certain circumstances.
set index in i18n.qml to -1, old settings were just for reading from the bogus model
current model uses strings, so index fails to read from it. This fixes cala crashing on loading i18n.qml
- Expand the documentation, emphasize octal-vs-decimal
- east-const consistently in this file (most of Calamares is west-const)
- shuffle the is-valid bool to the end of the data members,
so sorting by size.
- already had methods for various kinds of broken-up data, but
not one for plain "region/zone" strings; having this makes
it easier for QML to report a zone.
- use the region/zone method from QML, so that clicking on the
world map updates the actual TZ in Config.
- get network status from the global Network object; document that
- get the strings describing the language and LC settings from
the config-object instead of roll-our-own
- use the model of supported locales from Config to populate listboxes
- connect selection of language or LC to the Config object
- remove stray and useless TODOs
- remove unnecessary empty overrides
- clean up includes
- drop all the code that is now in Config
Since the business logic (setting locations, maintaining GS, ...)
is all in the Config object, the ViewStep is remarkably simple:
hook up a UI to the Config, which in the case of QML is done
automatically.
- since the Page hooked up a model and changed the region-selection
**after** connecting to signals, it would reset the location
to Africa/Abijan (alphabetically the first timezone) during
construction. Don't do that.
- this doesn't do the lookup **yet**
- while here, refactor setConfigurationMap so it reads like a story,
with chunks bitten out into a handful of static inline void methods.
- read the *region* and *zone* settings; this duplicates what
the ViewStep does and is currently unused, but ..
- add new support for using the system's TZ (rather than
the fixed values from *region* and *zone*). This complements
GeoIP lookup.
This is the actual feature that started the long rewrite of
the Config object (so that all the business logic would be in
one place, usable for both widgets and QML).
FIXES#1381
- writing *localeConf* settings to GS can be done always when the
formats are set, rather than special-cased. The code
that handles the "special case" of no widget existing for the ViewStep
overlooks the other crashes that happen then.
- Since Config knows what jobs to create, just ask it rather than
keeping a copy.
