- when an emergency strikes, log the modules that are skipped
with a Once, but if an emergency module runs, refresh that
Once so that the function header is printed again -- to
distinguish JobQueue debugging from the logging from the
emergency module.
- Transifex tools complain about missing Q_OBJECT (which makes
some sense -- you end up with a different context for calls
to tr(), of the base class).
Prompted by Linlinger, I've reconsidered the names of languages
in the drop-down in the welcome page. We already have the
infrastructure for assigning specific names / locales to
"Calamares locale names" (which match Transifex names, not
necessarily Qt names). Use that to put exactly two Chinese-
language translations in the drop-down:
- Simplified Chinese (code zh_CN)
- Traditional Chinese (code zh_TW)
Drop zh (which is a peculiar locale name anyway) and zh_HK
(which is Traditional Chinese, but using the geographic
boundary is a bit weird; we're going to ignore the
minor orthographic differences with Traditional Chinese
written elsewhere for now).
Note that this makes the drop-down show "Chinese"
in the English column, twice; the difference is visible
only in the native-language representation.
SEE #1741
With old Qt, Calamares could only run one check on a thread,
because the NAM would be switched to NotAccessible --
subsequent checks would fail because the NAM is already
hard-set to NotAccessible, so it could never be turned back
on by Calamares code.
Reset the accessible flag for the NAM while checking if
the internet is there.
- was filtering out the wrong URLs
- was not actually removing the invalid URLs
- extend API to make it possible to count / confirm the settings
- extend tests to demonstrate that API and the issues
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.
- enforce consistent [PYTHON JOB]
- use CDebug() constructor, because the convenience macro's
introduce the function name -- that's the C++ function, so
it isn't useful for logging.
Just have **one** Retranslator object, and install it as event-filter
(this needs to be done manually on a top-level widget) and use
signals / slots to do the actual work, rather than filtering
in multiple places and doing our own mediocre version of binding-
signal-to-lambda.
Sending a Once to a logger that isn't enabled should not "consume"
that Once; it's still available for a subsequent logger that **is**
enabled (useful if you're using more than one log-level in a function).
This allows injecting arbitrary Python code before
the script of a module is even run. For testing
purposes, that gives us a chance to modify existing
(internal) modules before the script (e.g. to test
subprocess calls).
- The log **file** got every QDebug object, while stdout only
got the ones of sufficient logging level. A CDebug object checks the
logging level before writing anything -- so those already were
consistent, but any qDebug() in the program (not cDebug()!) would
reach the writing-function anyway, and so log to the file.
Fix this weird inconsistency by checking log-level just once,
for both writes.
