- These have **not** been fixed for validation, so the schema's themselves
will fail to load. This is a consequence of variations in JSON-Schema
representations through various drafts. Fixing the schemata is
fairly straightforward.
This gives us 19 new tests, all of which fail.
- Let's just have one header definining export- and visibility-
macros for Calamares. They are still selected based on the
export flags (*_PRO), just defined in one header instead of two.
- This small header file contained a few unrelated typedefs.
Move those typedefs to the classes they relate to. This
**does** mean that some consumers need to #include something
else instead.
- Use type names more consistently.
Editorial: why are **pages** responsible for creating the jobs?
- These methods are used for multi-page view-steps, which are rare.
For all the others, just drop the empty implementation and defer
to the base class.
This basically means we talk about localization in the respective
localized variant. e.g. "German (Germany)" ➡ "Deutsch (Deutschland)".
If geoip lookup failed or isn't configured for whatever reason it's a
stretch to expect the user to know english enough to find their own
language. Preferring the localized strings resolves this issue.
Additionally this happens to bypass #712 respectively
https://bugreports.qt.io/browse/QTBUG-34287
as the native names are properly spelled. So, as long as Qt has localized
names the names will also be properly spelled.
- In many cases, using QLatin1String is a de-optimization, when
applied to a C string literal. Kevin Kofler pointed out that
those should basically all be QStringLiteral, instead. (Compile
tests with -O3 show that in the optimized object file, the
code size difference is negligible).
- Drop the explicit constructor entirely in cases where we're calling
QProcess::execute(), for consistency.
- Do a little less messing around in the mapping of keyboard locales
to keyboard map names.
Use QProcess::execute() with the 'safer' argument-list, rather than
escaping and de-escaping strings. Also reduce noise by only passing
a variant if there is one.
Split locale into <language>_<country> and go looking for keyboard
layouts that match. Do that in reverse, so look for country first.
- known weakness is el_CY (should get layout gr) because CY and el
don't name any keyboard layout.
- known weakness are Hausa, Igbo .. which are ha_NG and ig_NG. They select
keyboard layout ng, which is labeled "English (Nigeria)"; they ought
to select ng(hausa) and ng(igbo), which are the right variant keyboard
layouts to use.
- similar selecting a locale in Canada (en_CA, fr_CA, iu_CA ...) will
select keyboard layout ca, which is for French-speaking Canada.
Locale en_CA should select keyboard en -- e.g. en(us). But iu_CA
(Inuktituk) needs layout ca(ike).
