- 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
- 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.
- since all locale changes need to be entered into GS anyway, this
is something the Config object can do because it is the source
of truth for locale settings.
- drop all the GS settings from the Page.
- remove the weirdly-structured prettyStatus and similar:
the Config object has human-readable status strings (three,
for location, language, and LC-formats) which can be
normal properties with signals.
- Implement prettyStatus in the view step by querying the Config.
- the language and LC settings migrate from page to config
- add API for explicitly setting language (which is then preserved
when clicking new locations)
- since Config knows what settings there are, it should create the
jobs to run later -- not the Page.
- this doesn't work yet, because the Config does **not** know what
the selected timezone is yet.
- all the TZ location information now lives in the Calamares
locale service and the TZ list
- replace the Location class that was local to the timezone
widget by the TZZone class
- chase a bunch of small API changes that this needs
- search for a key and return a type-cast pointer to the result
- while here, simplify some other code
- the find() function could be done with std::find_if but doesn't
get any shorter or more elegant
- By using QList< CStringPair* > consistently, we can save
a bunch of model code at the cost of an occasional dynamic_cast;
it's fairly rare for there to be a need for the derived pointer.
- Use namespace CalamaresUtils::Locale consistently for this service.
- Move locale-related non-GUI support code from the Welcome module
to libcalamares; these are generally useful. Both Label (naming a locale)
and LabelModel (managing a bunch of those Labels) have been moved.
- The language and BCP need to be in-sync
- Existing code was inconsistent in setting things, which is why
you could get through the locale page without setting a locale
(at all) or it would keep English in spite of picking Germand on
the welcome page.
- Patch tests to use that API.
- Allow split-setting of the language and formats
- Test new constructors
- Since fromLanguageAndLocation can handle empty localeGen
lists just fine, skip all the weird checks that return
invalid guessed locale configurations.
- Replace createDefault() with a constructor that takes a
locale name; use it with en_US.UTF-8 in those places where
createDefault was previously used.
