Nothing beyond the example module was ever built with the
PythonQt bindings, as far as I can tell. They have been
deprecated, defaulting OFF for over two years now.
QML modules fill the gap with customizable, run-time
interpreted UI and stronger support from the C++ side
of Calamares.
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.
This is intended for consumption by QML; the ViewManager object
acts as a proxy for a handful of global Settings values already,
so throw in global Logger values as well. A QML module that would
like to read the log file (e.g. for tailing it as part of a
slide-show) can get the path via this property.
- offer a convenience method for showing a popup and
URL information and copying the URL to the clipboard
- use that from ViewManager (on failure) and DebugWindow (on demand)
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.
For methods that log a bunch of things, and which want to
consistently use SubEntry, but don't know when the **first**
log entry is within the method, Logger::Once can be used
to log one regular message (with function info) and the
rest are subentries.
- this test would fail if the logfile already exists for
any reason (including "I just ran the test")
- remove the file before expecting an empty logfile
- improve messages; a missing logfile is not a "things cannot
work" situation, it's a warning
This tests only the termbin ("fiche") paste by sending it
a derpy fixed string. Prints the resulting URL, doesn't
verify in particular.
It'd be rude to run this test too often.
- mark functions with STATICTEST so they can be compiled into a test
- move logfile-reading so we can call the pastebin-upload functions
with an arbitrary payload.
- The Paste API promises just a (string) URL back, not
a whole message, so return just the URL from the
abstract API and the concrete (fiche) implementation.
- Set clipboard contents from the UI
- Build (translated) message in the UI code
- have a namespace Paste with just one entry point, which will handle
untangling type &c.
This doesn't compile, but indicates the direction to take the API
- Use just type and url, since port can be specified in
a URL. Note that we only use host and port, not the
scheme (or the path, for that matter).
- Factor out understanding the *uploadServer* key to a function.
- get a QByteArray rather than going through a char[] buffer
- bytes-read is not important since the RE can only match if
there **are** that many characters.
- using the QML sidebar would not highlight the first step on startup,
only after next / prev would the highlight show up. Now, notify
when all the modules are loaded (and number 0 is active).
- Some minor bits snuck in with the string-truncation code
- While here, make UPDATE_BUTTON_PROPERTY more statement-like
so it doesn't confuse code-formatters.
Writing `Logger::NoQuote{}`` has annoyed me for a while, so
switch it to a constant, like SubEntry, so it looks more
like a regular manipulator object.
This improves the situation for jobs that do not provide
a status: their blank status does not overwrite the status
bar, and since (previous commit) the description or name
is used to start the job if the status is empty, at least
**something** is displayed.
SEE #1528
- parameter instanceKey was left over from previous work that
special-cased the weight of Python modules.
- while here, consistently do `~T() override`
With 1 CPU, Calamares still spawns 9 threads or so: eventloop,
dbus loop, QML loop, ... many of those are invisible to the
application. Contention occurs on startup when the UI is constructed,
and we end up with the module manager creating widgets alongside,
or ahead of, the main window UI. This can result in deadlock:
- in CalamaresApplication::initViewSteps
- in QML imports
This is partly because the signal-slots connections get "deep":
from loadModules() we emit *modulesLoaded* which ends up showing
the main window in initViewSteps(). Avoid this with a QTimer:
drop back to the event loop and release whatever locks are held,
so the QML thread can get on with it already. Then the timer
goes off and the view steps are created.
- 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.
- CC0-1.0 for the uninteresting version-headers
- GPL-3.0-or-later for the services
- add SPDX identifiers to Calamares C++ libraries and application sources
- add SPDX identifiers to Calamares QML (panels and slideshow)
- the `qmldir` is a list of names of things in the directory,
so CC0-1.0 it as "uninteresting"
- QRC files are lists of names of things in the directory,
so CC0-1.0 them as well
Some Calamares source files incorporate material from
3rd parties (unlike the 3rdparty/ dir, which is basically-
unchanged 3rd party source). Tidy up the FileCopyrightText
lines for those sources.
This is not an exhaustive effort.
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 weight is the module (instance) weight, which can be
- the default weight of 1
- the weight specified for the module (in module.desc / the module
descriptor; this defaults to 1, above)
- the weight specified for the instance (in settings.conf)
The last of these "wins"; weights are constrained to 1..100
The weight isn't actually used in progress computation yet.
In 022045ae05 a regression was introduced: if no *slideshowAPI*
is specified in the branding file, Calamares refuses to start, with
a YAML failure.
Before the refactoring, we had `YAML::Node doc` and looked up
the *slideshowAPI* in it with `doc["slideshowAPI"]`. After the
refactoring, we had `const YAML::Node& doc`. The `const` makes
all the difference:
- subscripting a non-existent key in a mutable Node silently
returns a Null node (and possibly inserts the key);
- subscripting a non-existent key in a const Node returns an
invalid or undefined node.
Calling IsNull() or IsScalar() on a Null node works: the functions
return a bool. Calling them on an invalid node throws an exception.
So in the **const** case, this code can throws an exception that it
doesn't in the non-const case:
`doc[ "slideshowAPI" ].IsScalar()`
- Massage the code to check for validity before checking for scalar
- Add a `get()` that produces more useful exception types when
looking up an invalid key
- Use `get()` to lookup the slideshow node just once.
- Add access to the panel-sides membe of the view manager, and
calculate which sides are populated by panels (if any).
- Pass the calculated panel-sides to the view manager before it
starts adding viewpages, so they get consistent margins.
- All the headers go to relevant subdirs, but we don't keep
libcalamares and libcalamaresui apart.
- While here, remove unused variable from libcalamares CMake
- link the library privately -- the public API uses QVariantMap
- install FindYAMLCPP just in case
- add yamlcpp explicitly in the few places that really need it
(e.g. netinstall testing the parsing of netinstall.yaml)
- Add the Calamares CMake-modules to the search path automatically
- Export to CalamaresTargets.cmake and use namespace Calamares::
- Document imported targets
- Find Qt, because the translations machinery will need macros from that
- The installed lib links to IMPORTED libraries from KF5, so we need
to find them (again) as well.
- When loading QML V2, both loadQmlV2Complete() and changeSlideShowState()
lock the same mutex, introduced in e7f4479df1.
- Explicitly unlock when loading is done and we need to change the state
immediately.
- For testing purposes, it's useful to load a module externally
and then register it to the ModuleManager (this hands off ownership).
- Refactor overall module loading to use the exposed single-module method.
- QML files need to be searched in specific places; this was initialized
by Calamares, but not for the text application. Move initialization
into the library.
- Previously, unless setDefaultFontSize() was called explicitly,
the default size would be 0, leading to unexpected and weird
displays (and a warning on stderr).
- If setDefaultFontSize() is not called, get a sensible size instead
(like defaultFontHeight() was already trying to do).
- It is the requirements model (checking) that reports progress, and now
the model is accessible (ask for it with requirementsModel(), make the
messages come from there.
- The architecture of letting someone build up a list of requirements
from data emitted by the ModuleManager is broken: if it gets loaded
later, it will miss data; passing around complicated objects is
no fun anyway. Get rid of it, on the way to "ModuleManager has
its own model of requirements".
- Give the ModuleManager a RequirementsModel -- that is the source
of truth about the module-requirements of the modules managed
by that particular ModuleManager.
- Let the RequirementsChecker operate on a given RequirementsModel.
Doesn't compile (but I need to get it off this machine)
- Prepare to implement a picture-based slideshow alongside QML
- Split QML loading into the slideshow component
This might be good prep-work for moving QML loading out of the QMLViewStep as well.
- This code has existed for a long time but never stored anything
to the Branding object, and the most literal slideshow (just some
images) was not implemented.
