The distinction CalamaresUtils and Calamares is old-fashioned,
since we can use nested namespaces (and already do) for a lot
of things; make libcalamares/locale/ a bit more consistent
by using namespace Calamares::Locale for everything.
When the checks were done, the widget showing the countdown-timer
and results was not being informed, so it didn't update the
display of the countdown timer or hide the list of problems
(when there are none) so that the welcome image is shown.
FIXES#1974
- for QML, this is the easiest way to factor out the message
(no convenient access to free functions, unless I bung the
message into e.g. Branding where I don't think it fits
very well).
Because of the way Qt interprets the environment variable
LANG, using `sr@latin` or `sr@latn` or `ca@valencia` would
get you `sr` or `ca`, respectively, which isn't an exact
match. Now that Translation has special-handling for
those values of LANG, match with the ID first.
This allows starting Calamares in Serbian (Latin script)
or Catalan (Valencia) for locales that need it. (Qt doesn't
recognize ca@valencia as a variant, since that's a region-
based locale, not country- or script-based)
The model was emptied-and-refilled when re-checked, which
meant we needed to have some special handling when messages
changed to avoid re-creating widgets. Since we use a model
view now, we don't need the extra machinery.
This is a rather clunky implementation of re-check requirements.
"Clunky" because the UI parts are re-created each time, rather
than fishing from a model of checked (or unchecked) requirements.
The Widgets parts should be updated to use a full model, rather
than the recreate-list-of-Widgets implementation they have now.
Unrelated changes pull in a bunch of improvements to the
waiting spinner widget.
While here, make it possible for the "screen" (screen-size) check
to be mandatory; there's no reason it shouldn't follow the same
logic as all the others (although denying users an install because
they have a VGA monitor seems a bit weak).
- improve descriptive-strings in logging ("set?" is not very
meaningful)
- log only the unsatisfied entries, since the preceding
log-message suggests that that is what is happening.
This is intended to apply translations to some common Qt UI components.
Example: a QMessageBox with standard buttons OK and Cancel; the text
for that is determined at startup using the system locale, and later
changes to the current locale or the current translation catalog,
do not affect OK and Cancel. It might be possible to load a catalog
with the right translation strings, except that there is no way to
know what the context or catalog **is** for the strings that are
used to label standard buttons: they can come from Qt base, or
the platform, or the theme. Merely loading the Qt Base translations
for the correct language does not help, because those translations
do not contain an "OK" string with the context used for standard
buttons.
Do the translation by hand; then we have all of the Calamares
languages covered, too, which is more than the Qt translations do.
- improve logging
- fix failing tests -- the observed and expected behavior is
to fill in a fallback check-URL, not change to an empty list,
- **except** if there's no requirements key in the config
at all; this is a bit weird, but let's make the tests
document existing behavior so we can notice if it changes.
