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.
- do not link (explicitly) to Calamares libraries, the CMake
functions do that automatically.
- while here, tidy and remove commented-out-bits
- while here, remove unneeded includes
- 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).
Widgets are easier to style if they have a name, and easier to spot
in the widget tree as well. Give the requirements-checker
parts meaningful names.
SEE #1685
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.
In spite of there being considerable documentation sometimes in the
config file, we go with CC0 because we don't want the notion of
'derived work' of a config file.
The example `settings.conf` is also CC0. Add some docs to
it while we're at it.
The build instructions are not that interesting, it's a toss-up
between CC0 and BSD-2, but because other CMake bits are BSD-2-Clause,
apply that to more CMakeLists. The copyright date isn't all that
accurate, but these are just inconsequential files.
While here, tidy up and get rid of some useless intermediates.
The .ui files are all GPL-3.0-or-later style, but it's
slightly difficult to keep licensing information in them:
it's XML, so an XML comment might work, but there's no
guarantee that safe/load will preserve them.
Put the SPDX tags in the <author> tag, so that it's visible
in Qt Designer.
- Note that this is missing *languageIcon* so if that gets uncommented,
it will fail validation.
- While here decide that should be
right up front in object (mappings) declaration.
- The requirements are collected by ModuleManager, checked
by an internal RequirementsChecker and changes to the
requirements state are all signalled from ModuleManager.
By connecting the requirements in the welcome modules' Config
only to their own configs -- and immediately checking them,
which is bad on its own -- we end up with a disconnect between
what the ModuleManager says about requirements, and what
the welcome modules report on.
- 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.
- things that can be done in the designer file should be there,
not weirdly repeated in code elsewhere
- drop the insertion of an extra spacer (why not include it in the
designer file?)
- shuffle all the connect() calls down to the end of the constructor
- 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.
- these were empty, so the widgets were hidden in the details
dialog of the requirements check; which looks really strange
if the reason the check fails is because root is required,
and you can't see that in the details.
This commit is on a branch because it changes strings, and I want
to do a release Real Soon and not annoy the translators.
- instead of counting and needing to keep track of the predicate
applied while creating the widgets, push nullptrs to the widget
list instead reflecting "this entry did not satisfy the predicate
for widget creation".
- for the list, the code can be the same as for the dialog,
only the predicate is different.
- while here, implement retranslate() since there's no text on
the list widgets otherwise.
- Create the label once, and it's ok for it to respond to links
even if there's none in the code.
- Turn into a member variable in preparation for retranslation-refactor.
- lift it out of the loop that creates the widgets
- some lambda-wankery, but the compiler hammers this down to
simple loops and you can read the resulting code as
none_of [the list] isUnSatisfied
none_of [the list] isMandatoryAndUnSatisfied
- no point in having init() called immediately after the constructor,
if it only makes sense to have one call to init() ever to create
the widget.
- while here, give it the same kind of structure as the dialog,
holding on to a reference to the list.
