- 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 Config object can hold all of the configuration information,
including also the requirements-checking parts. Move requirements-
checking configuration there, so it is shared and consistent
across welcome and welcomeq, regardless.
This repairs the test that expects the Config object to handle
**all** of the configuration, too.
- Branding, Settings, and ModuleManager may all be nullptr,
in which case the corresponding code shouldn't call methods
of those instances -- this is demonstrated by just creating
a Config object
QString -> Id for translations in the external API, to avoid
accidentally converting a QLocale name (e.g. ca_ES) into a
Calamares translation name. This preserves special-cases
like ca@valencia and sr@latin.
- the message had been arbitrarily changed; change it back
- update (warning) message when there is progress in checking the
model, so it doesn't stay at "unchecked" until you change language
- minor clean-ups
- The Config object owns the requirements model, and has messages /
strings describing the state of the model. Use that message,
dropping the duplicate message from the requirements widget.
- Re-jig to pass the Config object around rather than the model
that it owns.
- This does not work, because translation events do not arrive
(and the slot isn't called automatically either).
Require a ; after RETRANSLATE macros. They are statement-like;
this makes it easier for some of them to be recognized by
clang-format and resolves some existing weird formatting.
- point to main Calamares site in the 'part of' headers instead
of to github (this is the "this file is part of Calamares"
opening line for most files).
- remove boilerplate from all source files, CMake modules and completions,
this is the 3-paragraph summary of the GPL-3.0-or-later, which has
a meaning entirely covered by the SPDX tag.
- The Config object can handle GeoIP loading on its own. Both
View steps that used this had a derpy view->setCountry() that
didn't really do anything with the view anymore.
- start of a class to hold configuration information; this can
later be substituted into the WelcomeViewStep and filled from
setConfigurationMap()
In the example application:
- register the Config type
