- 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.
- 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
- test application to display the QML (this will be extended
with adding the locale model to it)
- sample QML that does nothing useful yet (will display the locale
model once it's there)
- This helps give meaningful names to code chunks
- Gives clang-format something to work with
- Reduces indentation depth
I think this is a bit of a code-style opinion issue: big complicated
lambdas doing UI things just don't seem like a good idea.
- the "Select language" tooltip was applied to the form, so it would
show up inappropriately all over the place
- the buttons didn't have useful tooltips.
- having show*Url and donateUrl seems inconsistent, although
the show*Url settings were originally boolean-only.
- add "show" to the Donate button setting, to make them
all consistent (putting a boolean there will generate a
warning and hide the button, that's all).
- the generic (enum-based) setupButton() can handle all four
of the buttons, so setupLinks() can go away. Only the
(re)translation of the text on the button needs to be
done, so move that to the main RETRANSLATE.
- Handle buttons and their URL-opening in a more
general way with an enum; drop existing three-boot
method and special setupDonateButton()
- Doesn't compile because consumers haven't changed.
As the config files integer are now of type `QVariant::LongLong` instead
of `QVariant::Int`, requirements relying on this type were not parsed
correctly.
This patch fixes this, and adds an option to the python conversion to
take into account `QVariant::LongLong` types.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
- FIXES#934
- Whether this is really wanted depends on the distro, and I'm not
100% convinced the likely tags from Unicode are correct (or it'd
take a lot more data). In any case, starting Calamares in "NL"
gets me "nl_NL" as translation; presumably starting it in "BE"
will get me that as well (what about Les Wallons?)
- This also shows off that it's a real hack to have so much program
logic in the *widget* parts of each ViewStep. Longer-term,
a lot of functionality should go to the ViewStep itself, which
will then control the UI.
- Which translations are available is a global property
of Calamares itself, not of the plugins, so getting
the model of available translations should live there.
Move the relevant code (which is simple) from the
Welcome module.
- 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.
