Read, then write, the NM file. Add a note about how we might
handle this better. Rename live_user() function to give it
a verb (and avoid UnboundLocal when using a variable of the same name).
This class doesn't really set a pointer -- it is a scoped assignment
through a pointer, which **can** set a value on destruction (when
it leaves scope). Rename it.
While here, extend the API so that it can do an assignment to the
underlying object **now**, while also doing a scoped assignment
later when it leaves scope. This makes some code a bit easier
to read ("in this scope, X is now <v> and then it becomes <v'>")
This class was used only once, and is confusing because
the assignment happens always, but to the opposite value
as what was visible. It can be replaced with other
scoped assignment, instead.
Removes the tests for it, too.
- 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.
- iterate over the lines of the source file, rather
than over indexes, and make clear that the hooks, modules and files
lines are replaced, rather than merged.
- this calls write() more often, but it's only a few lines
- don't chain directly from modify_mkinitcpio_conf() to the
function that writes the file write_mkinitcpio_lines();
split into "figure out what needs to be written" and calling
that writing-function, so that we can test / check / log
if needed between the two.
- put the system-information and -detection functions at top
and the "do the actual work" things below
- don't mix the boolean do-we-use-this flags with the
lists of files and modules which are the important
parts of modify_mkinitcpio_conf
- 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).
Move some of the texts to the new TranslationFix, from ViewManager,
and use them. Keep them in ViewManager, too, so that the translations
with context ViewManager are not removed just now.
This is intended to apply translations to some common Qt UI components.
Example: a QMessageBox with standard buttons OK and Cancel; the text
for that is determined at startup using the system locale, and later
changes to the current locale or the current translation catalog,
do not affect OK and Cancel. It might be possible to load a catalog
with the right translation strings, except that there is no way to
know what the context or catalog **is** for the strings that are
used to label standard buttons: they can come from Qt base, or
the platform, or the theme. Merely loading the Qt Base translations
for the correct language does not help, because those translations
do not contain an "OK" string with the context used for standard
buttons.
Do the translation by hand; then we have all of the Calamares
languages covered, too, which is more than the Qt translations do.
Move the CMake code responsible for building the translations from
the src/calamares directory (yeah, yeah, the translations need to
link into the executable) into lang/ (which is where the source
and other infrastructure lives).
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
