- 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.
- QVector is a better match with passing in QStringList, otherwise
you end up dealing with Qt's int indexes vs. std::vector's uint
indexes everywhere.
- Introduce find()
- Don't use this if we don't need it (QObject::tr is static).
- C++14 allows (copy) binding to arbitrary expresstions in lambda's,
so detach from this.
- 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.
- Next was enabled early; presumably to cover the case that no requirements
were checked and the requirements checker never emitted an update signal.
Drop that since the module manager is now responsible for doing that checking.
- The NAM is being created from a method call on the GeneralRequirements
object in the requirements-checking thread, while the GR object itself
was created in a different thread. This cross-thread parenting
produces a warning, and we don't need the parent relationship here
anyway.
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.
- document accessors
- put all path and directory accessors together
- make simple accessors inline
- rename "pathprefix" to "directory" to be consistent with others
- Some locales have no nativeLanguageName(), so instead display
the locale id (e.g. "eo") and the resulting language in English
(which, if it is really unsupported, will be "C").
- The QLocale constructor which takes a string (locale name) doesn't
understand sr@latin, and returns the Cyrillic locale. Fix that
by creating locales ourselves for @latin locales.
- sr and sr@latin now display correctly in the right script in the
native language dropdown.
- The (RTL) text "Arabiy (Misr)" should be entirely RTL, so
make the parenthetical insert -- which would otherwise be LTR
and so mess up the placing of those parenthesis around the country --
explicitly RTL.
- Since there are no RTL languages in Calamares right now with
country-local translations, this isn't visible.
- A locale suggests it is country-specific by having the form <lang>_<country>
- This mostly fixes locale "ar" being presented as "Arabiy (Misr)" when
there is no need to (and the RTL is messed up then, too).
- Introduce intermediate data class for building up the list
of languages to present.
- Sort on the English names, with en_US at the top (ugh).
- Show the native names.
